6 ms·

I dont buy this argument at all. Any sufficiently complex Python 2 project does not work with Python 3 without modification, there is _no_ cross-version compati

by antpls 6y ago

I dont buy this argument at all. Any sufficiently complex Python 2 project does not work with Python 3 without modification, there is _no_ cross-version compatibility. And if you wanted to try that yourself anyway, changing all .py to .py3 in a directory is one unix command... It could easily have been part of a 2to3 tool

kd5bjo 6y ago
The issue is third-party libraries: They need to simultaneously support both versions of Python during the transition period. If you unilaterally migrate to v3, you break lots of existing projects. On the other hand, if you stay v2 only, you‘re holding up your dependent projects’ migration efforts.
- antpls 6y ago
  I understand the benefit in theory, but in practice, you had two options : - the codebase had to be modified to work on both versions at the same time - you had to maintain two versions in different branches for a while Is there any data to show which options was most often chosen amongst all pypi packages? I suspect that the second option was more popular for the most important packages of the ecosystem
  - lopuhin 6y ago
    The first option was by far the most popular and was used for years (including pip), only recently packages started dropping python 2 support. I'm not even aware of any packages which went with the second.
  - pseudalopex 6y ago
    They made option 1 possible because people complained about option 2. six was the #2 package on PyPI.[1] It's a library to help with option 1. [1] https://python3wos.appspot.com/ https://python3wos.appspot.com/
  - user5994461 6y ago
    "the codebase had to be modified to work on both versions at the same time" This. This is the only option. I can tell you in decades of experience with I don't know how many companies and language, this is ALWAYS the option that is done.
  - masklinn 6y ago
    > I suspect that the second option was more popular for the most important packages of the ecosystem You're 100% wrong. The few packages which decided on option 2 early on (e.g. dateutil) ended up having to roll back to option 1 because it was such a pain in the ass, both for the maintainer and for downstream users. The migration only really started happening once 2.7 dropped, projects like Six[0] started appearing, and the community started ignoring 2to3 and building up experience with cross-version projects and idioms (e.g. [1], [2]) [0] whose entire point is to help with option 1 [1] https://eev.ee/blog/2016/07/31/python-faq-how-do-i-port-to-python-3/ https://eev.ee/blog/2016/07/31/python-faq-how-do-i-port-to-p... [2] https://python-future.org/compatible_idioms.html https://python-future.org/compatible_idioms.html
masklinn 6y ago
> I dont buy this argument at all. Any sufficiently complex Python 2 project does not work with Python 3 without modification, there is _no_ cross-version compatibility. I was personally and solely responsible for migrating a >250kLOC project from Python 2 to Python 3, doing so without cross-version compatibility would not have been feasible. We literally picked the earliest P3 version we decided to support based on cross-compatibility features.

by antpls 6y ago

kd5bjo 6y ago

The issue is third-party libraries: They need to simultaneously support both versions of Python during the transition period. If you unilaterally migrate to v3, you break lots of existing projects. On the other hand, if you stay v2 only, you‘re holding up your dependent projects’ migration efforts.

antpls 6y ago
I understand the benefit in theory, but in practice, you had two options : - the codebase had to be modified to work on both versions at the same time - you had to maintain two versions in different branches for a while Is there any data to show which options was most often chosen amongst all pypi packages? I suspect that the second option was more popular for the most important packages of the ecosystem
- lopuhin 6y ago
  The first option was by far the most popular and was used for years (including pip), only recently packages started dropping python 2 support. I'm not even aware of any packages which went with the second.
- pseudalopex 6y ago
  They made option 1 possible because people complained about option 2. six was the #2 package on PyPI.[1] It's a library to help with option 1. [1] https://python3wos.appspot.com/ https://python3wos.appspot.com/
- user5994461 6y ago
  "the codebase had to be modified to work on both versions at the same time" This. This is the only option. I can tell you in decades of experience with I don't know how many companies and language, this is ALWAYS the option that is done.
- masklinn 6y ago
  > I suspect that the second option was more popular for the most important packages of the ecosystem You're 100% wrong. The few packages which decided on option 2 early on (e.g. dateutil) ended up having to roll back to option 1 because it was such a pain in the ass, both for the maintainer and for downstream users. The migration only really started happening once 2.7 dropped, projects like Six[0] started appearing, and the community started ignoring 2to3 and building up experience with cross-version projects and idioms (e.g. [1], [2]) [0] whose entire point is to help with option 1 [1] https://eev.ee/blog/2016/07/31/python-faq-how-do-i-port-to-python-3/ https://eev.ee/blog/2016/07/31/python-faq-how-do-i-port-to-p... [2] https://python-future.org/compatible_idioms.html https://python-future.org/compatible_idioms.html

masklinn 6y ago

> I dont buy this argument at all. Any sufficiently complex Python 2 project does not work with Python 3 without modification, there is _no_ cross-version compatibility. I was personally and solely responsible for migrating a >250kLOC project from Python 2 to Python 3, doing so without cross-version compatibility would not have been feasible. We literally picked the earliest P3 version we decided to support based on cross-compatibility features.