6 ms·

Why should Guido or PSF get to tell people to stop using Python 2 even if they no longer want to work on it? It's ungraceful not to hand off maintainership on g

Why should Guido or PSF get to tell people to stop using Python 2 even if they no longer want to work on it? It's ungraceful not to hand off maintainership on good terms to someone who wants to do the work. Imagine if Stroustrup had done D and insisted that it be called C++ and wanted everyone to stop using the language everyone knew as C++ on Jan 1st 2020.

dragonwriter 7y ago
> Why should Guido or PSF get to tell people to stop using Python 2 even if they no longer want to work on it? They aren't stopping people from using Python 2, the language or Python 2, the software. They are stopping people from using the name “Python” as the name of forked implementations of Python 2 not maintained by the PSF. No implementation not maintained by PSF is allowed to be called unqualified Python; the name is an important indicator of provenance. There are and have been plenty of third-party Python (2 and otherwise) implementations, the implementations just need their own names.
- hsivonen 7y ago
  > They aren't stopping people from using Python 2, the language or Python 2, the software. The effort to claim the binary name python for Python 3 is actively hostile to Python 3 and a thing that runs unmodified Python 2 unmodified on the same operating system installation. (It's unclear to me how much this is a PSF push, but at least the PEP isn't telling distros to refrain from this hostile-to-comaptibility action.) > No implementation not maintained by PSF is allowed to be called unqualified Python The best situation would be PSF hosting continued Python 2-compatible development by people who want to do the work.
  - joshuamorton 7y ago
    > The best situation would be PSF hosting continued Python 2-compatible development by people who want to do the work. For who? This costs the PSF manpower/overhead that they don't want to expend on a thing they don't want to maintain. It dilutes the language that the PSF are stewards of, and would further cause a schism in the python community. None of those things sounds good for python, its ecosystem, or the PSF. They sound good for, like, a few curmudgeonly companies and individuals that don't want to migrate. I can't parse your first sentence, so I can't respond to it.
    - hsivonen 7y ago
      > For who? For users of the Python 2 language who have a lot of Python 2 code and for whom migration doesn't make cost/benefit sense on technical merits of Python 3. There's Tauthon. There's Active State's long-term support for Python 2. There's presumably Red Hat's long-term for Python 2. There are probably others. Also, there's the need to keep the server side of pip up and running for these to work. It would be great if there was a common venue for collaboration for these by the parties who are interested in keeping Python 2 going. (I'm not suggesting that Python 3 core devs should do the work.) Like a foundation for Python software. The first sentence meant that claiming the command-line executable name python for Python 3 is hostile to letting an execution environment for Python 3 and an execution environment for Python 2 co-exist going forward without having to modify existing programs that assume that python is for Python 2 and python3 is for Python 3.
      - joshuamorton 7y ago
        > The first sentence meant that claiming the command-line executable name python for Python 3 is hostile to letting an execution environment for Python 3 and an execution environment for Python 2 co-exist going forward without having to modify existing programs that assume that python is for Python 2 and python3 is for Python 3. Yes, but I don't believe I've seen any (real) suggestions to change PEP 394. > There's Tauthon. Which I claim is actively bad for python's ecosystem in the long term. It shouldn't be supported by any organization that wants what is best for Python. > There are probably others. Also, there's the need to keep the server side of pip up and running for these to work. That works just fine without any help. pypi continues to support python2 tags and wheels, and I doubt that'll change anytime soon. > There's Active State's long-term support for Python 2. There's presumably Red Hat's long-term for Python 2. So the entire reasonable bit here is that the PSF should provide something to help various enterprise companies manage backporting security patches. Which, like, I'm not sure what infrastructure is actually needed for that. They already make security patches public. Unless you're suggesting that LTS enterprise support offerings should co-ordinate additional feature work on python 2, which is both unusual and again I claim actively harmful to the ecosystem.
  - takeda 7y ago
    That project is not Python 2 though, it added features that made it incompatible with both Python 2 and Python 3. Just look at their effort to add wheel support. Any project that forks changes name: nagios -> icigna mysql -> mariadb NetBSD -> OpenBSD FreeBSD -> DragonflyBSD Python -> PyPy, Jython, IronPython It would be crazy for them to keep the same name and not be compatible. It would cause confusion and also lead to increase of support tickets in wrong bug trackers.
    - hsivonen 7y ago
      In those cases, the original project lived on. Here Python 3 is the incompatible fork, but because the technical fork is done by the folks who control the name and who want to shut the old thing down, so the compatible evolution of Python 2 had to change the name.
gjulianm 7y ago
Your analogy is not appropriate. The actual situation with Tauthon is as if someone was not happy with C++17, so they forked C++14, added new features and changed syntax and then insisting to call it C++. It's just confusion for the users and it's in the best interest of the PSF to protect the Python name.
- hsivonen 7y ago
  I'd agree if the Python core devs were still interested in evolving Python 2.x. But they aren't, so now no one else gets to do Python 2.8, either. It would be the best if the PSF provided a venue for Python 2.x development even if the folks who went on to do Python 3 weren't the people working on it. Anyway, the core problem is a top-down effort to try to make a programming language of Python 2.x’s level of usage stop to the extent it’s stoppable under its license, because its creators wanted to do something else, as opposed to facilitating its user community to pool resources to continue its development. Does the PSF have a legal obligation to do such facilitation? No. Is the lack of such facilitation bad for parties who bought into Python when it was Python 2? Yes.
  - joshuamorton 7y ago
    > core devs were still interested in evolving Python 2.x. They absolutely are. In fact, python 3.9 is in the works right now, which has many new evolutions beyond 2.7. You're arguing that the psf should treat python2 and 3 as different languages. In their (any my) opinion, this is harmful. It bifurcates python into two incompatible languages. That's bad long term (Perl). In other words, what's best for python the language, and what's best for python2 the language are not the same. And for the psf, python is more important.
    - hsivonen 7y ago
      > They absolutely are. In fact, python 3.9 is in the works right now, which has many new evolutions beyond 2.7. I meant compatible (in the sense that old programs keep running and you can add new stuff to old programs using the new features) evolutions. > You're arguing that the psf should treat python2 and 3 as different languages. For practical purposes, they are different languages and the PSF has been treating them as distinct things. > In their (any my) opinion, this is harmful. It bifurcates python into two incompatible languages. That's bad long term (Perl). It indeed is bad. I hope that every other programming language community and designer takes a close look at what happened and makes sure never to do a Python 3 analog of their language. > In other words, what's best for python the language, and what's best for python2 the language are not the same. And for the psf, python is more important. That's the core problem from the perspective of Python 2 users. The organization that was the steward of the language that they invested in (in the form of writing code in the language) decided not only that a different programming language is more important for the org but that the old language needed to be shut down in order to benefit their new thing. It's OK for people to get bored with a project and move onto something else, but with the level of usage that Python 2 had and has, it's very problematic for the language steward organization to turn around and seek to shut the language down instead of continuing to evolve it in a way that's respectful of the language users' investment in the language.

dragonwriter 7y ago

> Why should Guido or PSF get to tell people to stop using Python 2 even if they no longer want to work on it? They aren't stopping people from using Python 2, the language or Python 2, the software. They are stopping people from using the name “Python” as the name of forked implementations of Python 2 not maintained by the PSF. No implementation not maintained by PSF is allowed to be called unqualified Python; the name is an important indicator of provenance. There are and have been plenty of third-party Python (2 and otherwise) implementations, the implementations just need their own names.

hsivonen 7y ago
> They aren't stopping people from using Python 2, the language or Python 2, the software. The effort to claim the binary name python for Python 3 is actively hostile to Python 3 and a thing that runs unmodified Python 2 unmodified on the same operating system installation. (It's unclear to me how much this is a PSF push, but at least the PEP isn't telling distros to refrain from this hostile-to-comaptibility action.) > No implementation not maintained by PSF is allowed to be called unqualified Python The best situation would be PSF hosting continued Python 2-compatible development by people who want to do the work.
- joshuamorton 7y ago
  > The best situation would be PSF hosting continued Python 2-compatible development by people who want to do the work. For who? This costs the PSF manpower/overhead that they don't want to expend on a thing they don't want to maintain. It dilutes the language that the PSF are stewards of, and would further cause a schism in the python community. None of those things sounds good for python, its ecosystem, or the PSF. They sound good for, like, a few curmudgeonly companies and individuals that don't want to migrate. I can't parse your first sentence, so I can't respond to it.
  - hsivonen 7y ago
    > For who? For users of the Python 2 language who have a lot of Python 2 code and for whom migration doesn't make cost/benefit sense on technical merits of Python 3. There's Tauthon. There's Active State's long-term support for Python 2. There's presumably Red Hat's long-term for Python 2. There are probably others. Also, there's the need to keep the server side of pip up and running for these to work. It would be great if there was a common venue for collaboration for these by the parties who are interested in keeping Python 2 going. (I'm not suggesting that Python 3 core devs should do the work.) Like a foundation for Python software. The first sentence meant that claiming the command-line executable name python for Python 3 is hostile to letting an execution environment for Python 3 and an execution environment for Python 2 co-exist going forward without having to modify existing programs that assume that python is for Python 2 and python3 is for Python 3.
    - joshuamorton 7y ago
      > The first sentence meant that claiming the command-line executable name python for Python 3 is hostile to letting an execution environment for Python 3 and an execution environment for Python 2 co-exist going forward without having to modify existing programs that assume that python is for Python 2 and python3 is for Python 3. Yes, but I don't believe I've seen any (real) suggestions to change PEP 394. > There's Tauthon. Which I claim is actively bad for python's ecosystem in the long term. It shouldn't be supported by any organization that wants what is best for Python. > There are probably others. Also, there's the need to keep the server side of pip up and running for these to work. That works just fine without any help. pypi continues to support python2 tags and wheels, and I doubt that'll change anytime soon. > There's Active State's long-term support for Python 2. There's presumably Red Hat's long-term for Python 2. So the entire reasonable bit here is that the PSF should provide something to help various enterprise companies manage backporting security patches. Which, like, I'm not sure what infrastructure is actually needed for that. They already make security patches public. Unless you're suggesting that LTS enterprise support offerings should co-ordinate additional feature work on python 2, which is both unusual and again I claim actively harmful to the ecosystem.
- takeda 7y ago
  That project is not Python 2 though, it added features that made it incompatible with both Python 2 and Python 3. Just look at their effort to add wheel support. Any project that forks changes name: nagios -> icigna mysql -> mariadb NetBSD -> OpenBSD FreeBSD -> DragonflyBSD Python -> PyPy, Jython, IronPython It would be crazy for them to keep the same name and not be compatible. It would cause confusion and also lead to increase of support tickets in wrong bug trackers.
  - hsivonen 7y ago
    In those cases, the original project lived on. Here Python 3 is the incompatible fork, but because the technical fork is done by the folks who control the name and who want to shut the old thing down, so the compatible evolution of Python 2 had to change the name.

gjulianm 7y ago

Your analogy is not appropriate. The actual situation with Tauthon is as if someone was not happy with C++17, so they forked C++14, added new features and changed syntax and then insisting to call it C++. It's just confusion for the users and it's in the best interest of the PSF to protect the Python name.

hsivonen 7y ago
I'd agree if the Python core devs were still interested in evolving Python 2.x. But they aren't, so now no one else gets to do Python 2.8, either. It would be the best if the PSF provided a venue for Python 2.x development even if the folks who went on to do Python 3 weren't the people working on it. Anyway, the core problem is a top-down effort to try to make a programming language of Python 2.x’s level of usage stop to the extent it’s stoppable under its license, because its creators wanted to do something else, as opposed to facilitating its user community to pool resources to continue its development. Does the PSF have a legal obligation to do such facilitation? No. Is the lack of such facilitation bad for parties who bought into Python when it was Python 2? Yes.
- joshuamorton 7y ago
  > core devs were still interested in evolving Python 2.x. They absolutely are. In fact, python 3.9 is in the works right now, which has many new evolutions beyond 2.7. You're arguing that the psf should treat python2 and 3 as different languages. In their (any my) opinion, this is harmful. It bifurcates python into two incompatible languages. That's bad long term (Perl). In other words, what's best for python the language, and what's best for python2 the language are not the same. And for the psf, python is more important.
  - hsivonen 7y ago
    > They absolutely are. In fact, python 3.9 is in the works right now, which has many new evolutions beyond 2.7. I meant compatible (in the sense that old programs keep running and you can add new stuff to old programs using the new features) evolutions. > You're arguing that the psf should treat python2 and 3 as different languages. For practical purposes, they are different languages and the PSF has been treating them as distinct things. > In their (any my) opinion, this is harmful. It bifurcates python into two incompatible languages. That's bad long term (Perl). It indeed is bad. I hope that every other programming language community and designer takes a close look at what happened and makes sure never to do a Python 3 analog of their language. > In other words, what's best for python the language, and what's best for python2 the language are not the same. And for the psf, python is more important. That's the core problem from the perspective of Python 2 users. The organization that was the steward of the language that they invested in (in the form of writing code in the language) decided not only that a different programming language is more important for the org but that the old language needed to be shut down in order to benefit their new thing. It's OK for people to get bored with a project and move onto something else, but with the level of usage that Python 2 had and has, it's very problematic for the language steward organization to turn around and seek to shut the language down instead of continuing to evolve it in a way that's respectful of the language users' investment in the language.