3 ms·

> 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. E

> 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)

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)