3 ms·

Python 2 is only unmaintained because the Python foundation is refusing to let anyone "officially" take over support. There are thousands of programs in Debian

Python 2 is only unmaintained because the Python foundation is refusing to let anyone "officially" take over support. There are thousands of programs in Debian with less core developers than Python 2 working just fine.

maxerickson 7y ago
It's understandable that the PSF wouldn't endorse a maintainer. They can't stop someone from releasing something that runs just like Python 2 and has a different name.
- CJefferson 7y ago
  That's true, but it might make packaging tricky -- lots of the old Python 2 software people want to run will have '#!/usr/bin/env python' hard-wired in, and having to fix those would be annoying.
  - PeterisP 7y ago
    You'd have to fix those lines anyway, since /usr/bin/env python will be pointing to python3 executable in the new releases, not python2.
    - oconnor663 7y ago
      It's been that way on Arch Linux for years, but I wouldn't expect most other platforms to make that switch for some time, if ever.
      - saghm 7y ago
        Isn't this article an indication that Debian intends to? I'd also guess there's a pretty good chance that distros based on Debian (e.g. Ubuntu) will follow that switch
        mjw1007 7y ago
        As far as I know Debian intends to have no plain `python` on the default PATH once the python2 packages are removed, so that it will be up to the system administrator to decide where that will point. See eg https://lists.debian.org/debian-python/2018/05/msg00063.html https://lists.debian.org/debian-python/2018/05/msg00063.html from the Debian Python maintainer. (That's a year and a half old, but I haven't seen a message go past suggesting they've changed their minds.)
        saghm 7y ago
        Interesting! That seems like a reasonable solution to me, but I also have no dog in that race since I don't use Debian or write much Python code.
      - PeterisP 7y ago
        Starting next year, I'd expect most other platforms will not include python2 in the default distribution, so the default "python" can either point to python3 or nothing at all.
  - takeda 7y ago
    Upgrading the OS is also annoying, so why not just stay in one place for next 5, 10, 50? years. If you don't upgrade your machine it probably will continue to work, python 2 won't disappear. I wish PSF would pull the plug from python 2 much sooner so we wouldn't have to deal with whiners for 10 f...ing years. The problem with python 3 wasn't the incompatibility, the problem was keeping python 2 alive for so long. Other languages usually gave only 1 year and everyone moved, because they didn't want to stay behind.
    - CJefferson 7y ago
      Which other languages? My C89 code, C++98 code and Fortran 77 code all still compile on a modern Ubuntu, and none of these are expected to break any time soon. The compilers just support multiple versions.
      - joshuamorton 7y ago
        I'd strongly suggest watching "What is C++" [0] from this year's cppcon. There's a lot of good content, but the relevant bit is that c especially (remember, c++98 is younger than python2!) values backwards compatibility very highly. This is sometimes useful, but it has costs. Performance costs, safety costs, and especially ergonomic/complexity costs for future development (the kitchen-sink-ness of modern cpp). People aren't wrong to make different tradeoffs than you. Especially given that strict backwards compatibility is impossible (especially in a language like c/++, people will rely on things that aren't intentionally public, because they can introspect your bytes). Compiler changes break code all the time, it's just almost always semantic and not syntactic. I find this amusing, since the syntactic changes are usually easier to detect and fix. And python2 still works, it just won't get new features. [0]: https://youtu.be/LJh5QCV4wDg https://youtu.be/LJh5QCV4wDg
        hermitdev 7y ago
        > And python2 still works, it just won't get new features. Probably more importantly, it wont get security fixes. Yeah, Python 2 will still work. Ita not like there's a kill switch or anything. It just wont receive any official or supported updates. Effectively, Py2 will be abandonware.
  - skywhopper 7y ago
    Honestly, this seems like the easiest possible thing to fix of all the things that might be broken about older code.
  - jacquesm 7y ago
    For that we have symlinks.
  - catalogia 7y ago
    Surely the administrators of such systems can solve that problem with a few symlinks at most, not even code changes.
    - _kst_ 7y ago
      Sure, but those symlinks have to be consistently created and maintained, possibly on multiple new and existing systems. If you already have infrastructure that does similar things, it's probably not much of an issue, but I can see missing or misdirected symlinks being a common problem. Maintaining the symlink in the distribution (Debian or whatever) reduces the chance of errors.
      - catalogia 7y ago
        If there is any authentic popular demand for such a thing at all, I have no doubt that somebody in the python 2 community will see fit to publish a script that creates the appropriate symlinks.
        _kst_ 7y ago
        I have no doubt that multiple people will publish such scripts, and that they'll be subtly incompatible. (Cynical? Moi?)
  - samus 7y ago
    Package maintainers have to deal with worse things than that. Also, major distributions migrated their core packages to Python 3 a long time ago. Even if Python 2 was supported for longer, the Python 2 age is definitely over for system programming.
  - cbhl 7y ago
    Isn't Debian literally the one distro where that shouldn't be a problem? You create a package called "constrictor2.7", and set it up to provide /usr/bin/python using update-alternatives. Then #!/usr/bin/python and #!/usr/bin/env python both work.
- sitkack 7y ago
  In the case, the name is utility and not an artifact. I would argue that having the same name is necessary to even having a workalike, at least for a system command and a symlink. As long time Python user, my view of the PSF is that they could mature a little bit. Their ambivalent hostility towards PyPy and Jython, the lack of portable standard library, and now with how they are continuing to mismanage the 2to3 transition. None of this is how adults should behave.
viraptor 7y ago
You can fork it, rename it, and make it provide python2 binary via both Debian alternatives and package-provides, then ask for inclusion in upstream. There's nothing that stops you and it's done for other languages as well. For example in C you have GCC and llvm providing cc.
zanny 7y ago
Red Hat has already announced their intent to maintain Python 2 in RHEL for ~4 years.

maxerickson 7y ago

It's understandable that the PSF wouldn't endorse a maintainer. They can't stop someone from releasing something that runs just like Python 2 and has a different name.

CJefferson 7y ago
That's true, but it might make packaging tricky -- lots of the old Python 2 software people want to run will have '#!/usr/bin/env python' hard-wired in, and having to fix those would be annoying.
- PeterisP 7y ago
  You'd have to fix those lines anyway, since /usr/bin/env python will be pointing to python3 executable in the new releases, not python2.
  - oconnor663 7y ago
    It's been that way on Arch Linux for years, but I wouldn't expect most other platforms to make that switch for some time, if ever.
    - saghm 7y ago
      Isn't this article an indication that Debian intends to? I'd also guess there's a pretty good chance that distros based on Debian (e.g. Ubuntu) will follow that switch
      - mjw1007 7y ago
        As far as I know Debian intends to have no plain `python` on the default PATH once the python2 packages are removed, so that it will be up to the system administrator to decide where that will point. See eg https://lists.debian.org/debian-python/2018/05/msg00063.html https://lists.debian.org/debian-python/2018/05/msg00063.html from the Debian Python maintainer. (That's a year and a half old, but I haven't seen a message go past suggesting they've changed their minds.)
        saghm 7y ago
        Interesting! That seems like a reasonable solution to me, but I also have no dog in that race since I don't use Debian or write much Python code.
    - PeterisP 7y ago
      Starting next year, I'd expect most other platforms will not include python2 in the default distribution, so the default "python" can either point to python3 or nothing at all.
- takeda 7y ago
  Upgrading the OS is also annoying, so why not just stay in one place for next 5, 10, 50? years. If you don't upgrade your machine it probably will continue to work, python 2 won't disappear. I wish PSF would pull the plug from python 2 much sooner so we wouldn't have to deal with whiners for 10 f...ing years. The problem with python 3 wasn't the incompatibility, the problem was keeping python 2 alive for so long. Other languages usually gave only 1 year and everyone moved, because they didn't want to stay behind.
  - CJefferson 7y ago
    Which other languages? My C89 code, C++98 code and Fortran 77 code all still compile on a modern Ubuntu, and none of these are expected to break any time soon. The compilers just support multiple versions.
    - joshuamorton 7y ago
      I'd strongly suggest watching "What is C++" [0] from this year's cppcon. There's a lot of good content, but the relevant bit is that c especially (remember, c++98 is younger than python2!) values backwards compatibility very highly. This is sometimes useful, but it has costs. Performance costs, safety costs, and especially ergonomic/complexity costs for future development (the kitchen-sink-ness of modern cpp). People aren't wrong to make different tradeoffs than you. Especially given that strict backwards compatibility is impossible (especially in a language like c/++, people will rely on things that aren't intentionally public, because they can introspect your bytes). Compiler changes break code all the time, it's just almost always semantic and not syntactic. I find this amusing, since the syntactic changes are usually easier to detect and fix. And python2 still works, it just won't get new features. [0]: https://youtu.be/LJh5QCV4wDg https://youtu.be/LJh5QCV4wDg
      - hermitdev 7y ago
        > And python2 still works, it just won't get new features. Probably more importantly, it wont get security fixes. Yeah, Python 2 will still work. Ita not like there's a kill switch or anything. It just wont receive any official or supported updates. Effectively, Py2 will be abandonware.
- skywhopper 7y ago
  Honestly, this seems like the easiest possible thing to fix of all the things that might be broken about older code.
- jacquesm 7y ago
  For that we have symlinks.
- catalogia 7y ago
  Surely the administrators of such systems can solve that problem with a few symlinks at most, not even code changes.
  - _kst_ 7y ago
    Sure, but those symlinks have to be consistently created and maintained, possibly on multiple new and existing systems. If you already have infrastructure that does similar things, it's probably not much of an issue, but I can see missing or misdirected symlinks being a common problem. Maintaining the symlink in the distribution (Debian or whatever) reduces the chance of errors.
    - catalogia 7y ago
      If there is any authentic popular demand for such a thing at all, I have no doubt that somebody in the python 2 community will see fit to publish a script that creates the appropriate symlinks.
      - _kst_ 7y ago
        I have no doubt that multiple people will publish such scripts, and that they'll be subtly incompatible. (Cynical? Moi?)
- samus 7y ago
  Package maintainers have to deal with worse things than that. Also, major distributions migrated their core packages to Python 3 a long time ago. Even if Python 2 was supported for longer, the Python 2 age is definitely over for system programming.
- cbhl 7y ago
  Isn't Debian literally the one distro where that shouldn't be a problem? You create a package called "constrictor2.7", and set it up to provide /usr/bin/python using update-alternatives. Then #!/usr/bin/python and #!/usr/bin/env python both work.
sitkack 7y ago
In the case, the name is utility and not an artifact. I would argue that having the same name is necessary to even having a workalike, at least for a system command and a symlink. As long time Python user, my view of the PSF is that they could mature a little bit. Their ambivalent hostility towards PyPy and Jython, the lack of portable standard library, and now with how they are continuing to mismanage the 2to3 transition. None of this is how adults should behave.

viraptor 7y ago

You can fork it, rename it, and make it provide python2 binary via both Debian alternatives and package-provides, then ask for inclusion in upstream. There's nothing that stops you and it's done for other languages as well. For example in C you have GCC and llvm providing cc.

zanny 7y ago

Red Hat has already announced their intent to maintain Python 2 in RHEL for ~4 years.