9 ms·

> Matt knew that it would be years before the Python 3 port was either necessary or resulted in a meaningful return on investment (the value proposition of Pyth

> Matt knew that it would be years before the Python 3 port was either necessary or resulted in a meaningful return on investment (the value proposition of Python 3 has always been weak to Mercurial because Python 3 doesn't demonstrate a compelling advantage over Python 2 for our use case). What Matt was trying to do was minimize the externalized costs that a Python 3 port would inflict on the project. He correctly recognized that maintaining the existing product and supporting existing users was more important than a long-term bet in its infancy. Having just done transitions on a number of much smaller projects I had the same thought. Changes to string handling tripped me up and the changes to relative imports took some thinking. But the biggest frustration was the nagging question: Why am I doing this? edit: missing word

libria 7y ago
> Why am [I] doing this? Lack of security updates past 2019 forced our hand. Did you find a way around that?
- 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.
  - 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.

libria 7y ago

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

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.
- 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.