3 ms·

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

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

misnome 5y ago
> 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.
- Blikkentrekker 5y ago
  > 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.
simonh 5y ago
> 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.

misnome 5y ago

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

Blikkentrekker 5y ago
> 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.

simonh 5y ago

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