3 ms·

Renaming to a complete different name is not necessary, everyone understands a major version breaks compatibility. Python3 is still very close to Python2 both i

by antpls 6y ago

Renaming to a complete different name is not necessary, everyone understands a major version breaks compatibility. Python3 is still very close to Python2 both in syntax and spirit. But there was a sort of broken promise given by the Python creators: Python3 was almost like Python2, but every library author had to review and repackage their libraries, anyway. At that point, Python 3 should have been unambiguously incompatible with Python 2 : - the only allowed file extension should be py3 - all environment variables should have been duplicated with a "3" (it shouldn't read or modify Python 2 env vars) - all installation folders should have been duplicated with "3" - all tools like pip should be suffixed with "3" - and most importantly, it shouldn't try to optimistically run previous Python2 code or previous v2 tools The mistake was that you could use "pip" or "python" in bash scripts/shell, and not know if python2 or python3 were going to run. Still today, you can run "python" in a recent version of Ubuntu or Fedora, and it will be Python 3. Only "python3" should be possible. Distro are repeating the same mistake than with Python 2, and we will struggle again with Python 4, if there is any Python 4. Many headaches wouldn't have happened if "python" was reserved to Python 2. Pro tip to language and distro maintainers : make the major version part of the language name and executable, from version 1.

masklinn 6y ago
> - the only allowed file extension should be py3 That would have made cross-version codebases impossible, and that's what ultimately allowed migrating. One-shot migrations were not convenient, or successful, or even effectively feasible for complex enough projects. What allowed the migration was community experiment in cross-version sources, as well as reintroduction of "compatibility" features into Python 3.
- 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
sedatk 6y ago
> everyone understands a major version breaks compatibility That's not the case with C# or Java.
jart 6y ago
Why try to imagine the way it should have worked, when it shouldn't have happened in the first place. Python 3 was invented because Guido felt it looked nice, and the economic value of all the labor that went into pleasing him is likely equal to that of a small country.
feanaro 6y ago
There's a certain cognitive overhead and ugliness to having to run `tool3` instead of `tool`, which makes me dislike this solution.
alerighi 6y ago
That is not an elegant solution. That way you would forever had 3 in the name, even for future version of Python (e.g. python4, that will not break compatibility with old source code and thus making a .py4 wouldn't make sense). In your shell you don't run "java8" or "java11", you just run "java", and then it's the matter of what version of java JDK you have in your PATH. The same with all other language interpreters and compilers, you don't run gcc9 or node14. Why doing something different for python? Really, the mistake of python3 was to break compatibility with past programs. A lot of changes could have been done more gradually, in the first version require a __future__ import, then gradually remove compatibility with old features, and then remove them completely, making the new way the default and thus no longer require the __future__ import. And I think it will be the way for next python version, so in theory we will never have the same problem again. Also to me it was an error for distros to continue packaging python2 as python. Other distributions, like ArchLinux, switched everything to python3 as default a lot of time ago, it's only Ubuntu that continued to ship python2 as python, thus making a lot of programmers relying on it. It would make sense that the command without the name refers to the latest version, and not the legacy one.

by antpls 6y ago

masklinn 6y ago

> - the only allowed file extension should be py3 That would have made cross-version codebases impossible, and that's what ultimately allowed migrating. One-shot migrations were not convenient, or successful, or even effectively feasible for complex enough projects. What allowed the migration was community experiment in cross-version sources, as well as reintroduction of "compatibility" features into Python 3.

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

sedatk 6y ago

> everyone understands a major version breaks compatibility That's not the case with C# or Java.

jart 6y ago

Why try to imagine the way it should have worked, when it shouldn't have happened in the first place. Python 3 was invented because Guido felt it looked nice, and the economic value of all the labor that went into pleasing him is likely equal to that of a small country.

feanaro 6y ago

There's a certain cognitive overhead and ugliness to having to run `tool3` instead of `tool`, which makes me dislike this solution.

alerighi 6y ago

That is not an elegant solution. That way you would forever had 3 in the name, even for future version of Python (e.g. python4, that will not break compatibility with old source code and thus making a .py4 wouldn't make sense). In your shell you don't run "java8" or "java11", you just run "java", and then it's the matter of what version of java JDK you have in your PATH. The same with all other language interpreters and compilers, you don't run gcc9 or node14. Why doing something different for python? Really, the mistake of python3 was to break compatibility with past programs. A lot of changes could have been done more gradually, in the first version require a __future__ import, then gradually remove compatibility with old features, and then remove them completely, making the new way the default and thus no longer require the __future__ import. And I think it will be the way for next python version, so in theory we will never have the same problem again. Also to me it was an error for distros to continue packaging python2 as python. Other distributions, like ArchLinux, switched everything to python3 as default a lot of time ago, it's only Ubuntu that continued to ship python2 as python, thus making a lot of programmers relying on it. It would make sense that the command without the name refers to the latest version, and not the legacy one.