Comment by Blikkentrekker | Hacker News Reader

Comment by Blikkentrekker | Hacker News Reader

Parent Full thread

> Can we please stop complaining about Python 2to3 already. Feel free to use and maintain Python 2 indefinitely or move to a different language. Most of the rest of us will move on since the conversions were not that hard and the improvements worth it and we were given 10+ years to do it.

Have you done such an upgrade with a million line codebase?

No company wants to do that with such a large codebase with the potential of regressions that can cost quite a bit of money.

Reading this article makes it sound as though the experience taught him a valuable lesson and that he agrees that in retrospect Python 3 was a mistake, and it was.

There is quite a good reason why so many platforms and languages take indefinite backwards compatibility quit seriously. — it is simply a very demanding thing of large codebases to rewrite to a newer version of the language with all the potential of subtle regressions.

> The maintainers would probably do some things different with the 2to3 conversion if they had to do it over again.

The article suggests that if they could go back in time, they would not do it and make no backwards incompatible change to Python 2.

> But whatever mistakes were made weren't malicious and they were learning as they went just like the rest of us. I greatly appreciate their efforts to fix the things that were broken, regardless of the hassle involved in upgrading.

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.

This is why Rust uses editions and many other languages a system where backwards incompatible changes must explicitly be imported and the old behavior continues to be supported indefinitely.

> Have you done such an upgrade with a million line codebase?

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.

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.

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

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

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

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

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.

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

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

> and that he agrees that in retrospect Python 3 was a mistake, and it was.

You need to read it again. What he actually said was he should have provided more support to developers migrating code, not that he wouldn’t have done it.

Reply on news.ycombinator.com