15 ms·

> Why am [I] doing this? Lack of security updates past 2019 forced our hand. Did you find a way around that?

by libria 7y ago

hsivonen 7y ago
There's a project for keeping Python 2 alive: https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon It's particularly uncool that Guido brought up the prospect of lawyers (https://github.com/naftaliharris/tauthon/issues/47#issuecomment-266470996 https://github.com/naftaliharris/tauthon/issues/47#issuecomm...) to force it not to be called Python and opposed to letting people who care about keeping Python 2 alive evolve it as "Python 2". (I know he has the legal right to insist on the name change. Still uncool.)
- Klonoar 7y ago
  Longtime Python dev who was also annoyed by the 2 - 3 transition here. I don't see Guido as in the wrong for that. It'd be a smack in the face when you spend years trying to finally push people to switch (for better or for worse) and then a project like this takes the SEO and gets to run freely with it.
  - hsivonen 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? 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.
    - 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.
- hackbinary 7y ago
  I disagree. If someone else wants to continue to develop Python 2 outside the Python foundation and formalised development community, then that is their prerogative, but Python has the right to decide what is and is not Python. Dilution of what is commonly accepted to be Python would not be a good thing, and would further add to confusion. I know that platform upgrades are painful, but we need to move with the times or we'll all be mired in technical debt and old technology.
  - takeda 7y ago
    Yes, them keeping Python 2 alive for 10 years where Python 3 was developed caused a lot of issues, it would be extremely short sighted to allow third (incompatible) python into the mix.
    - hsivonen 7y ago
      > it would be extremely short sighted to allow third (incompatible) python into the mix The whole point of Tauthon is that it is compatible with Python 2 (in the direction that old programs work).
- mjw1007 7y ago
  I think it makes a great deal of sense for the Python core team to say "we're finished with Python 2 and want nothing more to do with it". But I'm very disappointed that the Python Software Foundation isn't explictly supporting people who want to keep Python 2 compiling and running on modern systems. I think that would be well within their remit to "promote, protect, and advance the Python programming language". This is particularly so because Python is widely used for scientific purposes, and being able to reproduce old results is valuable. Even before Python 3.0 appeared, I came across scientists saying "I prefer to stick with Fortran because new Python versions break old code too frequently".
  - int_19h 7y ago
    PSF does not object to people who keep Python 2 compiling and running, such as ActiveState (https://www.activestate.com/company/press/press-releases/activestate-offers-extended-support-for-python-2-beyond-eol/ https://www.activestate.com/company/press/press-releases/act...). This case is different, because it's a project that uses the Python name, but actively adds features to the language. This is the classic example of brand confusion - someone might try to use it, find something to complain about, and PSF's reputation suffers as the result. They also get support overhead from the users of the fork (even if all they do is tell them to go away, that is still triage time that could be spent on other issues).
    - mjw1007 7y ago
      "Does not object" is better than nothing, but I think it would be better if the PSF actively helped to coordinate this work (again, without bothering the core team). As far as I'm concerned, this is exactly the sort of thing that the PSF exists for.
  - forgotpwd16 7y ago
    >This is particularly so because Python is widely used for scientific purposes, and being able to reproduce old results is valuable. You can always download an old version and the respective libraries and use them to reproduce any results you want. That doesn't mean that old version should be supported anymore.
- Shorel 7y ago
  I downgraded Deluge to the Python 2 version because the new one doesn't work in Windows and I use both operating systems.
- simias 7y ago
  I understand your point of view but on the other hand we can make the parallel with Perl 5 and 6. Having incompatible forks of the language share the same name is a pain for everyone involved. I can completely understand the "mainline" python maintainers not wanting to have to deal with that. Besides if the Tauthon people are serious about maintaining their fork long term it needs to become more than a mere fork and a real language ecosystem of its own, in the long run having a different name will probably help with that, assuming that they ever get there. EDIT: Also reading the rest of the thread I realize that the post that you linked out of context is slightly misleading (but I blame github's aggressive folding more than you here). Guido's answer comes after the following exchange: stefantalpalaru: "Disregard Guido's objection. The "Python" trademark doesn't extend to "py2" or "py28". Read this for details: https://www.python.org/psf/trademarks/" https://www.python.org/psf/trademarks/" Guido: "Isn't the whole point that we're trying to solve this without lawyers?" stefantalpalaru: "The whole point is that you've been sabotaging Python 2 for years and when someone does what needed to be done from the start, you come up with silly objections." Guido: "OK, bring in the lawyers." In that light, and given the other poster's ridiculously inflammatory take, Guido's answer seems rather level headed and appropriate IMO. He stands his ground, so to speak.
  - lizmat 7y ago
    Re: I understand your point of view but on the other hand we can make the parallel with Perl 5 and 6. Please note that Perl 6 has been renamed to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). So Perl and Raku are now considered to be different languages, albeit from the same inspiration. Now, if Python 2 people would decide to rename Python 2 to something else, I guess it would be a mirrored parallel :-)
    - simias 7y ago
      That's precisely what's happening with the third-party Python2 forks. The renaming of Perl 6 occurred last October, specifically because of the problems caused by the confusion between the incompatible Perl 5 and 6 that caused a lot of trouble to the Perl people on either side for many years. It's not a mirrored parallel, it's the Python folks learning from Perl's mistakes and making sure that this parallel won't come to be.
- camgunz 7y ago
  Letting "Python 2" zombie around is unacceptable. Python 3 is better in every way, and has been since 3.3 (which Armin deserves a lot of credit for). Consider anyone who wants to build something with Python, whether it's a library, application, or service. What's better, having to build for Python 3 and 2, or just Python 3? Thank God that Guido did this, despite knowing all the blowback he'd get. To me, that's super cool.
  - eesmith 7y ago
    "better in every way" ... except for 1) startup time (according to the linked-to article), 2) support for existing Python 2 code, and 3) support for Python 2 C extensions. For example, https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/ https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stabili... describes the "Molecular Modelling Toolkit (MMTK), which might well be the oldest domain-specific library of the SciPy ecosystem, will probably go away after 2020. Porting it to Python 3 is possible, of course, but an enormous effort (some details are in this Twitter thread[1]) for which resources (funding plus competent staff) are very difficult to find." [1] The thread at https://twitter.com/khinsen/status/930749714567434240 https://twitter.com/khinsen/status/930749714567434240 includes "Lots of C modules written for Python 1.4 are waiting for enthusiastic code archeologists ;-)". I don't think Hinsen is alone in that situation. I can well believe there are some people who, for example, plan to retire in about 5 years and would rather keep with with a Python 2 zombie than spend time to port working code to Python 3.
    - camgunz 7y ago
      Startup time is complex, but base startup only increased about 20ms, and that's being generous. I'll admit Python 3 is still slower at a lot of things. But that feels like saying your new dog is even worse at math than your old one. The C extension thing isn't Python's fault. It's the job of library and app authors to update. Do we complain that Vulkan has bad SunOS support? This is totally backwards. Could Hinsen (and others) not just version their deps? It's not like people are erasing Python 2 off the internet. If his main worry is reproducibility, he should be doing that anyway. --- I don't want to give the impression I like the whole Python 3 thing. I think it was a pretty big mistake and a huge missed opportunity. I'm very sympathetic to people who had to put in a lot of work for basically no good reason--Python 3 didn't really offer anything significantly better than 2 until... 3.5 (3.4 if you think the first pass at async was useful, I personally don't). But I also find the ballyhooing about it really insufferable. Yeah it was a mistake; Armin Ronacher (as usual) was right. It was also over 11 years ago. Time to forget all about this and build cool stuff, please please please.
- MiroF 7y ago
  Did you see the other replies on the thread? Guido has absolutely every right here.
- stefantalpalaru 7y ago
  > It's particularly uncool that Guido brought up the prospect of lawyers [...] to force it not to be called Python It's much worse. The naming proposals were "py2" and "py28" - names for which they had no trademark registered. That made it clear that it was never about trademark protection. https://github.com/naftaliharris/tauthon/issues/47#issuecomment-266314206 https://github.com/naftaliharris/tauthon/issues/47#issuecomm...
falcolas 7y ago
> Lack of security updates past 2019 forced our hand. Did you find a way around that? Amazon is maintaining Python 2 for at least 4 years, as part of their Amazon Linux long term support release. Google app engine will support Python 2 for an unknown amount of time; they haven't announced an end date. PyPy is Python 2, with (to the best of my limited knowledge) no plans to deprecate support. There are also other LTS releases out there which include Python 2 support. IOW, the forcing function of the PSF no longer supporting Python is not as big a factor as was hoped.
- viraptor 7y ago
  This would only help the server side of mercurial though. There's no client-side supported distribution really. Pypy is not that popular yet.
  - falcolas 7y ago
    I don't know about others, but when I used Mercurial, it was via installing it through brew. And if brew installed pypy as a dependency so Mercurial could still use Python 2, I probably wouldn't have noticed.
    - viraptor 7y ago
      You'd notice, because it wouldn't work: https://www.mercurial-scm.org/wiki/PyPyPlan https://www.mercurial-scm.org/wiki/PyPyPlan
- rst 7y ago
  Security updates in Python itself aren't the only issue; a Python 2 project may also depend on packages with security issues of their own, which require continued upstream maintenance. For example, the python-saml package (for managing SAML-based single sign-on) has separate Python 2 and Python 3 versions, and implements a security-sensitive protocol which means it has (in the fairly recent past) gotten security updates for issues serious enough to rate an assigned CVE. If you're using it, having the current maintainers walk away from the Python 2 version is a serious risk...
kick 7y ago
PyPy is keeping Python 2 support indefinitely, I believe.

> Why am [I] doing this? Lack of security updates past 2019 forced our hand. Did you find a way around that?

by libria 7y ago

> Why am [I] doing this? Lack of security updates past 2019 forced our hand. Did you find a way around that?

There's a project for keeping Python 2 alive: https://github.com/naftaliharris/tauthon https://github.com/naftaliharris/tauthon It's particularly uncool that Guido brought up the prospect of lawyers (https://github.com/naftaliharris/tauthon/issues/47#issuecomment-266470996 https://github.com/naftaliharris/tauthon/issues/47#issuecomm...) to force it not to be called Python and opposed to letting people who care about keeping Python 2 alive evolve it as "Python 2". (I know he has the legal right to insist on the name change. Still uncool.)

Klonoar 7y ago
Longtime Python dev who was also annoyed by the 2 - 3 transition here. I don't see Guido as in the wrong for that. It'd be a smack in the face when you spend years trying to finally push people to switch (for better or for worse) and then a project like this takes the SEO and gets to run freely with it.
- hsivonen 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? 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.
  - 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.
hackbinary 7y ago
I disagree. If someone else wants to continue to develop Python 2 outside the Python foundation and formalised development community, then that is their prerogative, but Python has the right to decide what is and is not Python. Dilution of what is commonly accepted to be Python would not be a good thing, and would further add to confusion. I know that platform upgrades are painful, but we need to move with the times or we'll all be mired in technical debt and old technology.
- takeda 7y ago
  Yes, them keeping Python 2 alive for 10 years where Python 3 was developed caused a lot of issues, it would be extremely short sighted to allow third (incompatible) python into the mix.
  - hsivonen 7y ago
    > it would be extremely short sighted to allow third (incompatible) python into the mix The whole point of Tauthon is that it is compatible with Python 2 (in the direction that old programs work).
mjw1007 7y ago
I think it makes a great deal of sense for the Python core team to say "we're finished with Python 2 and want nothing more to do with it". But I'm very disappointed that the Python Software Foundation isn't explictly supporting people who want to keep Python 2 compiling and running on modern systems. I think that would be well within their remit to "promote, protect, and advance the Python programming language". This is particularly so because Python is widely used for scientific purposes, and being able to reproduce old results is valuable. Even before Python 3.0 appeared, I came across scientists saying "I prefer to stick with Fortran because new Python versions break old code too frequently".
- int_19h 7y ago
  PSF does not object to people who keep Python 2 compiling and running, such as ActiveState (https://www.activestate.com/company/press/press-releases/activestate-offers-extended-support-for-python-2-beyond-eol/ https://www.activestate.com/company/press/press-releases/act...). This case is different, because it's a project that uses the Python name, but actively adds features to the language. This is the classic example of brand confusion - someone might try to use it, find something to complain about, and PSF's reputation suffers as the result. They also get support overhead from the users of the fork (even if all they do is tell them to go away, that is still triage time that could be spent on other issues).
  - mjw1007 7y ago
    "Does not object" is better than nothing, but I think it would be better if the PSF actively helped to coordinate this work (again, without bothering the core team). As far as I'm concerned, this is exactly the sort of thing that the PSF exists for.
- forgotpwd16 7y ago
  >This is particularly so because Python is widely used for scientific purposes, and being able to reproduce old results is valuable. You can always download an old version and the respective libraries and use them to reproduce any results you want. That doesn't mean that old version should be supported anymore.
Shorel 7y ago
I downgraded Deluge to the Python 2 version because the new one doesn't work in Windows and I use both operating systems.
simias 7y ago
I understand your point of view but on the other hand we can make the parallel with Perl 5 and 6. Having incompatible forks of the language share the same name is a pain for everyone involved. I can completely understand the "mainline" python maintainers not wanting to have to deal with that. Besides if the Tauthon people are serious about maintaining their fork long term it needs to become more than a mere fork and a real language ecosystem of its own, in the long run having a different name will probably help with that, assuming that they ever get there. EDIT: Also reading the rest of the thread I realize that the post that you linked out of context is slightly misleading (but I blame github's aggressive folding more than you here). Guido's answer comes after the following exchange: stefantalpalaru: "Disregard Guido's objection. The "Python" trademark doesn't extend to "py2" or "py28". Read this for details: https://www.python.org/psf/trademarks/" https://www.python.org/psf/trademarks/" Guido: "Isn't the whole point that we're trying to solve this without lawyers?" stefantalpalaru: "The whole point is that you've been sabotaging Python 2 for years and when someone does what needed to be done from the start, you come up with silly objections." Guido: "OK, bring in the lawyers." In that light, and given the other poster's ridiculously inflammatory take, Guido's answer seems rather level headed and appropriate IMO. He stands his ground, so to speak.
- lizmat 7y ago
  Re: I understand your point of view but on the other hand we can make the parallel with Perl 5 and 6. Please note that Perl 6 has been renamed to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). So Perl and Raku are now considered to be different languages, albeit from the same inspiration. Now, if Python 2 people would decide to rename Python 2 to something else, I guess it would be a mirrored parallel :-)
  - simias 7y ago
    That's precisely what's happening with the third-party Python2 forks. The renaming of Perl 6 occurred last October, specifically because of the problems caused by the confusion between the incompatible Perl 5 and 6 that caused a lot of trouble to the Perl people on either side for many years. It's not a mirrored parallel, it's the Python folks learning from Perl's mistakes and making sure that this parallel won't come to be.
camgunz 7y ago
Letting "Python 2" zombie around is unacceptable. Python 3 is better in every way, and has been since 3.3 (which Armin deserves a lot of credit for). Consider anyone who wants to build something with Python, whether it's a library, application, or service. What's better, having to build for Python 3 and 2, or just Python 3? Thank God that Guido did this, despite knowing all the blowback he'd get. To me, that's super cool.
- eesmith 7y ago
  "better in every way" ... except for 1) startup time (according to the linked-to article), 2) support for existing Python 2 code, and 3) support for Python 2 C extensions. For example, https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/ https://blog.khinsen.net/posts/2017/11/16/a-plea-for-stabili... describes the "Molecular Modelling Toolkit (MMTK), which might well be the oldest domain-specific library of the SciPy ecosystem, will probably go away after 2020. Porting it to Python 3 is possible, of course, but an enormous effort (some details are in this Twitter thread[1]) for which resources (funding plus competent staff) are very difficult to find." [1] The thread at https://twitter.com/khinsen/status/930749714567434240 https://twitter.com/khinsen/status/930749714567434240 includes "Lots of C modules written for Python 1.4 are waiting for enthusiastic code archeologists ;-)". I don't think Hinsen is alone in that situation. I can well believe there are some people who, for example, plan to retire in about 5 years and would rather keep with with a Python 2 zombie than spend time to port working code to Python 3.
  - camgunz 7y ago
    Startup time is complex, but base startup only increased about 20ms, and that's being generous. I'll admit Python 3 is still slower at a lot of things. But that feels like saying your new dog is even worse at math than your old one. The C extension thing isn't Python's fault. It's the job of library and app authors to update. Do we complain that Vulkan has bad SunOS support? This is totally backwards. Could Hinsen (and others) not just version their deps? It's not like people are erasing Python 2 off the internet. If his main worry is reproducibility, he should be doing that anyway. --- I don't want to give the impression I like the whole Python 3 thing. I think it was a pretty big mistake and a huge missed opportunity. I'm very sympathetic to people who had to put in a lot of work for basically no good reason--Python 3 didn't really offer anything significantly better than 2 until... 3.5 (3.4 if you think the first pass at async was useful, I personally don't). But I also find the ballyhooing about it really insufferable. Yeah it was a mistake; Armin Ronacher (as usual) was right. It was also over 11 years ago. Time to forget all about this and build cool stuff, please please please.
MiroF 7y ago
Did you see the other replies on the thread? Guido has absolutely every right here.
stefantalpalaru 7y ago
> It's particularly uncool that Guido brought up the prospect of lawyers [...] to force it not to be called Python It's much worse. The naming proposals were "py2" and "py28" - names for which they had no trademark registered. That made it clear that it was never about trademark protection. https://github.com/naftaliharris/tauthon/issues/47#issuecomment-266314206 https://github.com/naftaliharris/tauthon/issues/47#issuecomm...

falcolas 7y ago

> Lack of security updates past 2019 forced our hand. Did you find a way around that? Amazon is maintaining Python 2 for at least 4 years, as part of their Amazon Linux long term support release. Google app engine will support Python 2 for an unknown amount of time; they haven't announced an end date. PyPy is Python 2, with (to the best of my limited knowledge) no plans to deprecate support. There are also other LTS releases out there which include Python 2 support. IOW, the forcing function of the PSF no longer supporting Python is not as big a factor as was hoped.

viraptor 7y ago
This would only help the server side of mercurial though. There's no client-side supported distribution really. Pypy is not that popular yet.
- falcolas 7y ago
  I don't know about others, but when I used Mercurial, it was via installing it through brew. And if brew installed pypy as a dependency so Mercurial could still use Python 2, I probably wouldn't have noticed.
  - viraptor 7y ago
    You'd notice, because it wouldn't work: https://www.mercurial-scm.org/wiki/PyPyPlan https://www.mercurial-scm.org/wiki/PyPyPlan
rst 7y ago
Security updates in Python itself aren't the only issue; a Python 2 project may also depend on packages with security issues of their own, which require continued upstream maintenance. For example, the python-saml package (for managing SAML-based single sign-on) has separate Python 2 and Python 3 versions, and implements a security-sensitive protocol which means it has (in the fairly recent past) gotten security updates for issues serious enough to rate an assigned CVE. If you're using it, having the current maintainers walk away from the Python 2 version is a serious risk...

kick 7y ago

PyPy is keeping Python 2 support indefinitely, I believe.