I honestly don't believe that many will step up and take over. Many will complain, but few will do the actual work.
Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.
There is Tauthon[1] which backports Python 3 features to 2 and seems to do the "actual work". It has been around a while.
It was also posted in this thread below by the current maintainer of the project but for some reason that comment was downvoted to [dead].
By reading a bit around about it, i do get the impression that the Tauthon developers face a bit of hostility from the Python community, so i'm not sure how viable it'll be in the long term. I suppose it depends on how stubborn the Tauthon developers are :-P
RHEL 7 depends on python 2.7 and will have security/maintenance support till June 2024. So for security updates, I guess we can just track RHEL7/CentOS7 python 2.7.
Also the longer a software is around, the lower the chance of some showstopper showing up (not 0% chance though)
What's most likely is that one important library in 2.7 stops talking to some upgraded system version (think OpenSSL for example) then what depends on it stops working.
> Many will complain, but few will do the actual work.
That's opensource in a nutshell.
If there are any big shops stuck on Python 2 then they will probably throw a resource or two at this. If there are big dists using Python 2 they will do the same.
From what I can tell, even Google is moving to python 3 (some of their previously python 2 only tools (like repo) have gained ‘experimental’ python 3 support) this year, so they’re probably not going to be doing the work.
> then they will probably throw a resource or two at this
Which, I'd guess, is probably gonna be 3 or 4 orders of magnitude more money than they've ever spent supporting Python2 (or 3) devs in the 10+ years they've built their own businesses on it while they sat on their hands and ignored the project's urging to upgrade to Python3...
Not a lot of sympathy from me for "big shops stuck on Python2"...
I'm no Python insider, but Google has quite a lot of projects based on Python 2, including build scripts for recently released software, so I'm guessing they could at some point maintain their own Python 2 branch (which, again, I'm guessing is much less work than porting a huge amount of script code over to 3 for no material benefit).
That's sort of hilarious... What are the incentives that prevent Google from upgrading their python 2 scripts to python 3? I guess it's more productive globally to stick with a supported version of Python 2.
Not the one you're responding to, but there are many cases where Python is used in the role of a shell script replacement eg. build scripting and test suite automation that wouldn't benefit from migration and, in fact, would suffer from half-assed migration attempts with little or no real-world testing.
Are you referring to that "Python 2.8" thing [1] that happened some years ago? A comment from PSF [2] makes it clear that they don't have any issue with people continuing to develop their Python 2 codebase further. It is what their open source explicitly permits after all.
They do have issue with people using a trademarked name and not making it clear that their work isn't endorsed by the Python Foundation.
For me, if I want most existing python2 programs to work, I'd want to release my program as called "python", so "#!/usr/bin/env python" continued to work.
If I'm not allowed to do that, then you are already adding a lot of friction to continuing to support existing python installs.
Although, I wonder if you could claim you need to call it that for the programs to work?
You've asserted this twice on this post, both times without any evidence. I Googled, couldn't find the threat you're basing the claim on, but DID find that the PSF Trademark Usage Policy (https://www.python.org/psf/trademarks/) explicitly allows most sorts of freely distributed Python-related products to use the name without permission:
> Use of the word "Python" in the names of freely distributed products like IronPython, wxPython, Python Extensions, etc. -- Allowed when referring to use with or suitability for the Python programming language.
We can quibble about whether a Python 2 fork would technically meet the definition here, but it seems to me that it would meet it at least as much as IronPython does; going after such a fork would contradict the rule implied by the examples in this section, even if it doesn't unambiguously violate the definition. I think they've already granted the public the right to use the word "Python" in a Python 2 fork and couldn't successfully sue over it now even if they wanted to.
What's your basis for suggesting that they've threatened to do so?
That is an absurd mischaracterization of the conversation. Guido’s response to the “py28” name was only, “Doesn’t work for me, sorry.” The “lawyers” response was specifically a response to an aggressive, insulting post from another poster. That other poster said that Guido should be disregarded, suggested names that would clearly get lawyers involved if chosen, accused Guido of sabotaging Python 2, and characterized Guido’s naming objections as silly. To Guido’s (virtual) face, no less! He was described by the original poster in that thread as hostile, antagonizing, and rude. Any reasonable reading of that single sentence post from Guido is of his giving up – throwing up his hands and saying the equivalent of “Well, whatever, then.”
---
gvanrossum: Isn't the whole point that we're trying to solve this without lawyers?
[redacted]: 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.
gvanrossum: OK, bring in the lawyers.
---
Just don’t appropriate a name what’s not yours, and you can maintain all the Python 2.x you want. Pathfinder[1] couldn’t call itself D&D 3.6 – Tauthon or anyone else can’t make things called Python.
CJefferson probably refers that GvR comment (Though I don't see that strong language here):
"""
Since I was asked: The project's name (and its binary name) need to change. They are misleading. The rest looks acceptable according to Python's license. This is not an endorsement (far from it).
"""
I think you're blowing it out of proportion. Call your project some other name. Say that your interpreter is compatible with Python 2 and that you provide continued support. It will probably be hard to find volunteers because most are moving/have moved to Python 3, but I don't think the threat of lawsuit will scare anyone away except those who want to infringe on PSF's trademarks and in that case...good?
I'm finding it difficult to understand why anybody thinks supporting Python2 should be done by volunteers?
What's "in it" for the volunteer? How much "fun" does "Supporting an old language where the original developers have moved on to a newer and more interesting version of the language, but there's a bunch of complaining people who still want the old language to be supported but they aren't offering to pay for it" sound? I'd rather sit in the park reading a book or walk a dog or something.
I mean, there's still people taking on COBOL contracts, because businesses consider their COBOL code to be important enough to keep maintained. But they sure as hell aren't "volunteering". They're getting paid rates that even bay area twenty-something FAANG-ers would be impressed by.
If Blackrock or The Vanguard Group or equivalent decided they needed continued Python2 support because it was a critical dependency on their ETF platforms (and they'd been foolish enough to not heed the "Goddamn it, just fucking upgrade to Python3 already!" advice from the core team for about a decade), I'm sure they could whip out their chequebooks and agree to a rate that Guido himself would agree support Python2 for them. But I'd hope and expect Guido (or whoever in the core team would be suitable candidates to do this work) to hold out for genuinely life-changing numbers of zeros on those cheques.
And if nobody is offering to write those cheques? Well maybe that says something about the seriousness of their complaints?
Continuing a fork under the original name would be confusing to everyone and bad manners, aside from infringing the trademark. But nobody is stopping people from organising around a fork called "Omphalos - a Python 2 fork" or whatever
Somebody has done just that already, it’s easily googleable. Nobody really cares though - why would you purposefully tie yourself to an objectively-inferior featureset, full of problems that have already been solved in py3? Because you can’t bear the use of parentheses for print, really?
> Because you can’t bear the use of parentheses for print, really?
While I generally share your POV, it doesn’t do justice to the situation to trivialize the upgrade like that. Anyone with C based dependencies will have a rougher time (but not that “rough”) due to ABI changes. The harder userland change is string handling anyway (which isn’t that hard either), not parens on print.
It would not be fork when the original project (Python 2) is no longer developed. There are many cases of cooperative maintainership handover without name change and nobody cares.
I understand using trademark as an advantage in cases of a hostile fork, but if the original maintainer no longer plan to do any bugfixing then it seems like a dick move.
The original project (Python) is still developed however. If a handoff to some other team occurs and the new maintainers do a bad job this reflects negatively on Python 3.
The motivation for that is probably avoiding what my first thought was; who is going to be the first to offer commercial extension of Python 2 support. That would be worth a lot of money to a lot of companies.
Even if it's just security fixes, there's still the process of testing and release management, and honestly, I don't blame the core Python team for no longer wanting to do release management of both Python 2 and 3.