3 ms·

> Yes. With a transition plan everything was ratcheted over to python3 syntax, then test compatibility. Now developers no longer have to remember the nuance bet

> Yes. With a transition plan everything was ratcheted over to python3 syntax, then test compatibility. Now developers no longer have to remember the nuance between python 2 and 3 and how to write compatibility layers for both. Then tell me, what were the costs of the transition when completed? and what where the projected costs when starting? > Now we no longer need to worry about maintaining or working around issues in dependencies that haven't been updated in a decade, and we don't need to teach python 2.7 to new developers. You wouldn't if Python 3 didn't exist either.

orf 5y ago
> It was certainly not malicious, but it was indeed a bad idea which is what the complaining is: that Python 3, or any such backwards incompatible changes should have never happened. > You wouldn't if Python 3 didn't exist either. This is a bit of a loony argument. There are so many useful features post py27 that may not have been possible without the breaking changes 2to3 introduced. Especially the horrific bytes/str situation in 2.7. So your argument is that Py3 shouldn't have happened, despite all of the people actually contributing to the language wanting it so (I wonder how much does company with your multi-million line project contributes to cPython's development?) and it unlocking future improvements that have driven Python adoption and usage into the stratosphere... because your company didn't want to invest any time or resources for ongoing maintenance? Of which upgrades are an obvious and important part?
- Blikkentrekker 5y ago
  > This is a bit of a loony argument. There are so many useful features post py27 that may not have been possible without the breaking changes 2to3 introduced. Especially the horrific bytes/str situation in 2.7. This situation could easily have been solved without breaking changes in a multitude of ways. > So your argument is that Py3 shouldn't have happened Yes, my argument is absolutely that none of the changes warranted breaking backwards compatibility. > despite all of the people actually contributing to the language wanting it so (I wonder how much does company with your multi-million line project contributes to cPython's development?) and it unlocking future improvements that have driven Python adoption and usage into the stratosphere... because your company didn't want to invest any time or resources for ongoing maintenance? Of which upgrades are an obvious and important part? That's merely an ad hominem, not an argument as to why you believe that the changes merited breaking backwards compatibility when there were far less intrusive ways to realize solutions that were close to as convenient but did not break backwards compatibility.
  - orf 5y ago
    > Yes, my argument is absolutely that none of the changes warranted breaking backwards compatibility. > That's merely an ad hominem, not an argument as to why you believe that the changes merited breaking backwards compatibility when there were far less intrusive ways to realize solutions that were close to as convenient but did not break backwards compatibility. You haven't made an argument, nor given any alternatives. You've just complained that the free work of others wasn't to your specifications. How would you propose handling the str/bytes situation without breaking backwards compatibility?
  - NoSorryCannot 5y ago
    Refusing to break backward compatibility is how you end up with some of the uncomfortable anachronisms that can be found in PHP and MySQL and other things. A language that did backward compat arguably well is Java but it had to be extremely conservative, a property that has made it popular to replace wholesale with languages that are nothing like Java. If it helps, you can convince yourself that Py3 is a different language that just happens to be very similar to Py2, and that Py2 needs new maintainers. This happens all the time.
  - joshuamorton 5y ago
    > This situation could easily have been solved without breaking changes in a multitude of ways. Please, do elaborate. (I'll note that if I were redesigning python3, I wouldn't settle on the design for unicode that py3 uses, something more rust-like is probably a bit better, but there's no way to transition from string-literals-are-bytes to string-literals-are-unicode without breaking backwards compatibility)
misnome 5y ago
> You wouldn't if Python 3 didn't exist either. It does exist. Python 2 is dead. The transition was more painful than it perhaps needed to be, but is IMO a better language for it than 2.7, or 2.6. PEP-3000 was 15 years ago. Complaining for decades about mistakes, that they admit, with hindsight, won't change anything.

orf 5y ago

> It was certainly not malicious, but it was indeed a bad idea which is what the complaining is: that Python 3, or any such backwards incompatible changes should have never happened. > You wouldn't if Python 3 didn't exist either. This is a bit of a loony argument. There are so many useful features post py27 that may not have been possible without the breaking changes 2to3 introduced. Especially the horrific bytes/str situation in 2.7. So your argument is that Py3 shouldn't have happened, despite all of the people actually contributing to the language wanting it so (I wonder how much does company with your multi-million line project contributes to cPython's development?) and it unlocking future improvements that have driven Python adoption and usage into the stratosphere... because your company didn't want to invest any time or resources for ongoing maintenance? Of which upgrades are an obvious and important part?

Blikkentrekker 5y ago
> This is a bit of a loony argument. There are so many useful features post py27 that may not have been possible without the breaking changes 2to3 introduced. Especially the horrific bytes/str situation in 2.7. This situation could easily have been solved without breaking changes in a multitude of ways. > So your argument is that Py3 shouldn't have happened Yes, my argument is absolutely that none of the changes warranted breaking backwards compatibility. > despite all of the people actually contributing to the language wanting it so (I wonder how much does company with your multi-million line project contributes to cPython's development?) and it unlocking future improvements that have driven Python adoption and usage into the stratosphere... because your company didn't want to invest any time or resources for ongoing maintenance? Of which upgrades are an obvious and important part? That's merely an ad hominem, not an argument as to why you believe that the changes merited breaking backwards compatibility when there were far less intrusive ways to realize solutions that were close to as convenient but did not break backwards compatibility.
- orf 5y ago
  > Yes, my argument is absolutely that none of the changes warranted breaking backwards compatibility. > That's merely an ad hominem, not an argument as to why you believe that the changes merited breaking backwards compatibility when there were far less intrusive ways to realize solutions that were close to as convenient but did not break backwards compatibility. You haven't made an argument, nor given any alternatives. You've just complained that the free work of others wasn't to your specifications. How would you propose handling the str/bytes situation without breaking backwards compatibility?
- NoSorryCannot 5y ago
  Refusing to break backward compatibility is how you end up with some of the uncomfortable anachronisms that can be found in PHP and MySQL and other things. A language that did backward compat arguably well is Java but it had to be extremely conservative, a property that has made it popular to replace wholesale with languages that are nothing like Java. If it helps, you can convince yourself that Py3 is a different language that just happens to be very similar to Py2, and that Py2 needs new maintainers. This happens all the time.
- joshuamorton 5y ago
  > This situation could easily have been solved without breaking changes in a multitude of ways. Please, do elaborate. (I'll note that if I were redesigning python3, I wouldn't settle on the design for unicode that py3 uses, something more rust-like is probably a bit better, but there's no way to transition from string-literals-are-bytes to string-literals-are-unicode without breaking backwards compatibility)

misnome 5y ago

> You wouldn't if Python 3 didn't exist either. It does exist. Python 2 is dead. The transition was more painful than it perhaps needed to be, but is IMO a better language for it than 2.7, or 2.6. PEP-3000 was 15 years ago. Complaining for decades about mistakes, that they admit, with hindsight, won't change anything.