>If people find catastrophic security problems in Python 2, or in software written in Python 2, then volunteers will not help you. If you need help with Python 2 software, then volunteers will not help you.
Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team if just security fixes are involved...
Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers...
No, the benefit of FOSS is that if the group developing a product does not support it anymore, you are free to fork it and support it yourself. And I am sure we will see a fair share of people doing that. What I am not sure is of anyone doing so will have the shoulders to actually support it.
Python 2.7 was released 1 decade ago. That's quite a long transition time.
Tongue in cheek comment; C was released 47 years ago and is still supported... but then again, that shows a very different philosophy between system languages and scripting languages.
It's much easier for C to be backward compatible, not because it's a system language per se but rather because it's so minimalist. You don't have problems dealing with unicode when you don't deal with unicode. You don't have a problem dealing with ranges and iterators when your most advanced looping construct is for(i = 0; i < 10; i++). Other more advanced and fully-featured system languages like C++, Rust or Go have a different story to tell and making them backward compatible comes at a significant maintenance cost.
Portability issues in C are mostly between architectures, not standard versions. The fact that "char" is normally signed on x86 but unsigned on ARM for instance is a common source of problems while porting code between these architectures. At least when you have python3 code you can be reasonably sure that it's going to run on any compliant python3 interpreter.
By the way, recently I realized that what I want is a language that does less instead of doing more. After all all these niceties with ranges and iterators are just syntactic sugar. Write pythonic code and face problems when porting this algorithm to C because C has nothing of Python niceties, which stop looking so nice at this point. Write non-pythonic C-like code without classes but with `__slots__` and functions all the way down and get not only the code that can be ported much easier to C and many other languages, but, surprisingly, also the code that is much more accessible and easier to reason about.
ANSI C is very different to the whole pre-ANSI zoo of C-like languages. Most of the code I saw from that age would never compile on modern post-ANSI compilers.
Nonsense. I just compiled a pretty large project from the stone age using a modern day compiler. It required a few lines of change in all to make it compile and it ran the first time it compiled.
C has many warts and design errors but they got the portability bit down quite well, the biggest problems you will run into are assumptions by programmers rarely assumptions by the designers of the language. One major thing lots of people tripped up over was endianness (sp?).
To be fair though, in 10 years time I'll still be able to build the last release version of Python2 (quite likely using a modern-in-2029-C-compiler) and use it to run whatever stone age Python2 code in need to run.
What people seem to be getting uptight about here, is that the volunteer Python language devs have collectively chosen to not fix any bugs or security problems discovered in the older Python2 language interpreter. I can't quite get my head around what the equivalent for that in C would be? There kinda _are_ no "language security features" in C, right? C is the archetype "How powerful a gun would you like to shoot yourself in the foot with today" language.
That you could easily port an old C code to modern compilers seems doesn't seem to be in contradiction to the statement that old code will not compile as is.
Prior to the ANSI standard there were many C compilers on different machines with different architectures.
Some compilers included support for architecture-specific things, like segmented memory, etc. Others allowed to do cross-function gotos. Types were not very well defined. Event the original language grammar from the book is only useful as an idea of what the language should be like, not as a proper syntax definition, I am not even talking about semantics here.
The code I had to deal with (written for 16-bit x86) had to be rewritten, it was definitely not a "fix-here-and-there" thing. It was fine, written by reasonable programmer and completely readable so I was able to understand and rewrite it in a week.
You probably were very lucky with that project of yours.
Even the way we have it nowadays C is... hard to formalise.
> I just compiled a pretty large project from the stone age using a modern day compiler.
Ok, now do the reverse. ;)
The work involved to upgrade from Python 2 to Python 3 for most things will be more like what you did (fixing a few things here and there), certainly not anywhere near as hard as what I challenged with above.
But backwards compatibility is the more useful direction to me, I can see however that if your job is to take a modern day application and compile it for a platform for which there is no modern day compiler that you're going to be in a special kind of hell for a long long time if the project has any size at all.
Not to mention that a system library is only as portable as the code you write for it, since inherently there’s usually a very small standard library of functionality that can be assumed across platforms. And all the support for systems generally rests on the system developer shipping support with C headers, etc.
Now it could be argued that C dialects are far more compatible with each other than Python 2 to Python 3, it could also be argued that linkers allow for code targeting one dialect to call code compiled for another dialect...
Once you go down that rabbit hole, though, there’s an argument that as most scripting languages are basically VMs with JIT compilation, then just like .NET and JVM, there’s nothing preventing scripting languages from inherently supporting multiple dialects via compiled intermediary representations...
That's not really a fair comparison. Python 2 probably _will_ be supported for decades to come, just not necessarily by the PSF. I'm sure that 99% of people and organizations supporting C 40 years ago do _not_ support C today.
I know you're writing tongue-in-cheek, but if you look at early C code you'll find it's not really supported today. The Lions book is full of "interesting" type magic, for example.
However the best analogy for python 2to3 is probably the prototyping changes of ANSI C, and we similarly offloaded the conversion of that code to external tools (protoize(1) and unprotoize(1)).
Likely the case. A lot of foot dragging took place. By five years ago most things of use were py3, conversion was easier than ever (and easy enough).
More importantly, it would have stopped piles and piles of bleakly futured py2 codebases being written. That people were still writing new py2 code five years ago is terrible, and the long sunset is certainly greatly at fault here.
That people are still writing new py2 code now is just criminal.
the RHEL vm's that I get at my job (enterprise IT) have python2 installed by default and no python3. It is much simpler to write scripts in python 2 (albeit written in a way to support forward compatibility with 3) because python2 is just there by default on every VM and its one less requisition order to write. We are actually upgrading to python 3 at the end of this month, but we lived with python 2 for a full year. Just want to make the point that "writing new py2 code now is just criminal" is a tad overzealous.
I'm pretty sure Twisted(!) did not have Python 3 support 5 years ago.
Also, macOS _still_ only ships with Py2. If I'm writing a quick script for my girlfriend to make her life easier, should I target Python 3 and force her to learn how to install xcode so she can learn to use homebrew so she can install Python 3, or should I just target Python 2 and move on?
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.
> Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers...
Well RedHat annouced a long time ago that RHEL 8 will drop support for Python 2 [0], so at least it appears they also want to leave Python 2 behind. RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me. Especially, behavior bugs and ports of Python 3 features to python 2 won't be done.
> RHEL7 is already receiving security fixes only [1], which doesn't look like a huge "support" effort to me.
Nobody expects new features in python 2.7, so this is basically all the support that people are looking for. RHEL7 will have security maintenance till Jun 2024.
As we see from the python3 switch motivation, the key support people need is support for their favorite libraries.
In that regard, maintenance for python 2.7 would involve backporting security fixes also for popular 2.7 third-party opensource libraries and frameworks even if those libraries themselves have already switched to python 3 only.
I wonder how many 3rd party Python2 libraries RHEL ships with?
I wonder if Redhat have left themselves enough weasel words in their contracts to say "Oh Python2? No security updates to the interpreter! Oh, you wanted explioted-library-de-jour updated? Well that's not covered in your support contract here. Left me put you through to our professional service division. Please have your contract ID and credit card number ready when they answer - transferring you now!"
I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...
> I'm 99.99% certain that if you ran "pip install numpy" on your RHEL7 box, and it's infected by a cryptominer the next day due to a know vulnerabilty, Redhat support are gonna laugh you off the phone when you call them up asking what they're gonna do about it...
If course they don't do fixes for all of pip / PyPI, nobody does/can be reasonably expected to do. They explicitly only cover what they ship (which does includes numpy and scipy, but not pandas). If you can demonstrate an exploit with just "yum install numpy" I'm pretty sure they'll work on it.
Volunteers can of course step up, nothing is preventing anybody. But you shouldn't expect it will happen. Why would anybody voluntarily work on fixing bugs in obsolete software?
People getting paid to work on Python (like at Red Hat) are not considered volunteers.
They say volunteers, so I think they mean just people working for free. In the next section they mention you can probably find support from your vendors or pay a third party to fix it. It then ends with the sentence
> If you need free help from volunteers, look at this help page.
Which links to the help page to learn python, haha. I think the point is that you can fork it or pay someone to fork it, but you won't find anyone else willing to fix your problems for free.
I think the volunteers here refers the Python core developers and committers. In contrast to cooperation-backed popular modern languages like JS, Python team has few full-time devs maintaining Python. [1] Most of them literally are volunteers.
They're announcing that the (small group of) people developing the Python2 executable are no longer going to do so after Jan 1st.
In what way does this imply that they're speaking for any "extended community"? Who're you trying to say is being mistaken here as being a "volunteer" but is not a 'PSF volunteer".
I totally get that there is an "extended community" around the Python language(s), including at least module authors, people who write Python frameworks, and people who write code in Python - and _possibly_ including devs at companies who have built products in Python or relying on Python. But it's 100% obvious that the linked article is referring to none of those people.
Who do you think this "FOSS org" was appropriately speaking for?
Uh, I think the PSF branding on that page is pretty clear. If you don't want to read a text in the context it's given that's your choice, but don't complain that it becomes ambiguous if read outside of its proper context.
Well, isn't it the benefit of FOSS, that volunteers can, and in the case of such a critical piece, so much used as Python 2, in all probability will, step up. Doesn't have to be the same people as the core team if just security fixes are involved...
Not to mention paid FOSS developers at places like RedHat, who want to keep supporting their LTS and enterprise customers...