>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.
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?
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.
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?).
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.
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'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.
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...
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.
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)).
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.
> 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.
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.
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.
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?
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).
"""
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.
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.
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
> 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.
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.
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?
You're technically correct in that GAE standard offers python 3, but it's not the same as their python 2 offering.
Python 2 is part of the first generation runtimes, python 3 is part of the second generation runtimes. They are not out of the box compatible, even if your python code works on 2 and 3. The first generation runtime included many APIs that are simply just not available in the second gen (you need to build them yourself). See link for more info.
I have numerous apps on their original standard environment. I'd have to rebuild huge parts of every single one of them for this completely different environment.
The original standard environment has a free tier and doesn't require billing and as such is great for everyone who can't or don't want to enter their credit card information.
As they are on CentOS 6 it would be impractical to switch to another version as default as Python is used by the system, however they do have 2.7 installed.
PHP-style shared hosting is not where Python users are. The shared-hosting story for Python has always been pretty bad, with rare exceptions (webfaction, before godaddy swallowed it). Python users are overwhelmingly on VPS and PaaS, where versions can be easily upgraded. Any PaaS provider without Python 3.6+ at this point is not worth paying for.
HostGator moves slow as frozen molasses but they do when they have to. Case-in-point, they rolled out Let's Encrypt support like the week that Chrome starting marking HTTP pages insecure.
I bet there is still some shitty hosting company somewhere offering Perl4 CGI script hosting.
Doesn't mean we should do anything except laugh at their incompetence (or perhaps be impressed by their ability to monetise other people's incompetence...)
No idea about CGI hosting, but I do allow perl 4 (and 3 and 2 and 1) scripts to run on my pastebin, https://perl.bot/ . In this case it's not incompetence but insanity.
That's also why I added COBOL, that and to test some ideas on how to handle compiled languages on it. The backend service supports multiple files but I haven't finished the web side of things to handle that (I have a strange requirement to make it work without javascript).
If you're after stupid suggestions, would it be "breaking your personal rules" to use only enough Javascript to allow just enough of a transpiled version of the in-browser Java runtime to let '90s vintage Java Applets run? Or maybe Flash?
(And no, I'm 100% not offering to do any of the work required to make that come true... ;-) )
I'd be willing to try something like that, but both flash and java applets are horrendously complex. The javascript restriction is because it's mostly used by us perl developers on irc and there's a few disgruntled greybeards that will actually use it via lynx or links. Closest thing for flash is shumway, https://mozilla.github.io/shumway/ which might be possible to make work but it's still got a lot of compatibility issues from what i hear.
Manually patching the source in a few places, most of the time it's just adding a header file or two since some of them predate ANSI C and the standardized header files. The other things have to do with adding -DHAS_... to force them to know that opendir and friends are actually present, so that make install will actually work.
Ugh? Many systems still run COBOL today. Python 2 is likely to be around for a long time. Since the stuff is open source, wouldn't it be nicer if it was possible to fix a bug if needed? Not saying that it should be actively worked on. But maybe one person could be appointed to look over bug fix pull requests (which shouldn't be that frequent these days).
Just don’t let your technical debt fossilize. At the beginning seems like a good idea to invest little money in supporting legacy rather than migrating it, but for example, supporting and maintaining COBOL applications is a huge headache. Companies even pay big bucks for formation of new professionals and integrate the old solutions with modern applications is not even that easy since some of the OS are even alien to TCP/IP interfaces let alone modern programming interfaces (and there is nothing worse than an HTML interface on top of the old non ANSI terminal interface, even if you knew where the F21 used to be)
COBOL has an upgraded version? Besides, legacy is not a perfect excuse for using python 2 since it's so similar to 3 and with some amount of effort you could port it over quite easily.
As someone who works on a 99% Python 2 codebase I think this is a very necessary step. Hopefully one of our larger customers will realise we are still running their critical infrastructure on Python 2 and make enough of a fuss that we can justify the expense.
Indeed, plus people will still come knocking at their door for Python 2 issues. And if you tell them to contact someone else for support people will still be upset.
Imho communicating EOL is the only way to go. Others can pick up legacy support under a different name. People will find them and it will be clear it's a different team.
The PSF isn't stopping anyone from continuing support. They are only stopping people from calling it Python 2 which is 100% reasonable given that (1) that is trademarked and associated with them and (2) they don't want others' confused about their association with the projects.
By the way this is market opportunity that HN readers might consider. If you think you can make money supporting Python 2, then start working. Who knows it could be a gold mine.
The latest official COBOL spec is COBOL 2014 and there are at least two or three competing companies out there that will happily sell you up to date COBOL tools and compilers. So while COBOL may be old, there are still new 'exciting' things happening in the COBOL space.
I don't think the main problem is to change the version of Python, but the version of all the related libraries, which many of them depend on 2.7 version.
I know many of the big ones are already on 3.x for a long time, but I wonder how long will it take to replace and upgrade all the small ones if it did not happen already...
BTW I don't know how necessary was to break compatibility between 2.7 and 3, the pain of this transition comes from that decision
Any major library that hasn't moved to Python 3 by now isn't going to on their own accord. Either that means they won't, or that the sunsetting will kick them into gear (or get their users to kick them into gear).
It should be pointed out that Python 2 will continue to be used, and be usable. It just won't get new security upgrades or features. I do not know, but I doubt if there will be a feature or security flaw come up soon that "forces" existing python 2-only libraries to update
I don't have a stake in this and don't know much about the background, so pardon if this comment is out of touch. Is this the first notice of this date? January 1 is just 16 weeks away, which seems like an awfully short notice for ending security updates of a very popular language.
EDIT: I see now that they mention that 2020 has been the plan since 2014, which seems reasonable.
It was announced in 2014 that the sunset day would be further extended to 2020. The original sunset date was 2015, announced in 2008.
That's more than 10 years ago that the intention to sunset python2 at a specific date was announced.
Anybody who, after 2008, started new, serious python2 projects that were supposed to have a life expectancy beyond a few years was rather "optimistic", and anybody who did after 2015 was almost callous, especially if you "played" with other people's money.
Is that the stance? I haven't heard anything on that front.
I'm sure there is a great market opportunity for some developers to do the migrations, or to alternative do backporting for some large companies not interested in mingrating.
(I've definitely seem other cases, but I can't find them). Here is someone wanting to call something 'py28', and Guido replies "OK, bring in the lawyers".
Why would anyone like python2 so much better than python3 that they would want to fork it into its own language? The two languages are already incredibly similar and python3 has a much larger active community.
I don't know if the author was intending to be hyperbolic -- I for one prefer Python 2's print. I would've preferred keeping print the way it was and using a new keyword for the new functionality.
The change in the print statement was also what put me off from Python 3 for a long while. But back then there where also no big benefits to be had from moving to 3. Nowadays I even prefer the print function as it makes it easer to convert to log functions.
I still don't see why the print function justifies trying to keep the language alive. You don't prefer that print act as a function and not a keyword? Maybe you don't, but is the change really not worth giving up 2?
Yup. By no means a developer, but I Python was the first programming language I learned and I always felt it was my native language. I was happy to stick around with 2.7 for as long as it was there, but I guess this is the motivation I needed to learn Ruby or Haskell. :-(
This doesn't make sense; if python 2 continues being developed then it will change for you. Besides, no one says you have to upgrade if you've found a version of 3 that you like, so what exactly is changing out from under you? The leap from 2 to 3 was not even that drastic. The entire changelog is incredibly short.
If I can't make the executable, by default on installing, be 'python2', I'm adding quite a lot of pain to users (in particular, all those users with #!/usr/bin/env python2 in scripts).
Tell your stick-in-the-mud customers to just symlink it. I sincerely doubt you will be sued for telling your customers to symlink `dead-snake` to `python` if they're really stubborn about not changing their code one whit.
They are effectively both dead or moribund. Jython has had a py3 experimental branch for ages but the entire project is basically starved of money and effort.
To be honest, the whole “Python on other runtimes” movement, as a concept, is more or less over. It’s just too much effort for too little reward, now that CPython has good libraries for pretty much anything you can think of.
PyPy is a python-focused project that builds a python-focused runtime. My comment was more about projects trying to retrofit Python on top of runtimes that were built for very different languages, typically because of some constraint that has now disappeared.
If the GIL is so important to you that you're willing to suffer the pain of running on another VM with a much-reduced ecosystem, while at the same time having requirements so complex that PyPy cannot meet them, maybe Python is just not the right tool for the project.
It's always good to see such big movements but as a truly peaceful p2 dev, I'm not even considering to upgrade my projects unless it'd cost me labor not to upgrade.
Given that you said "projects", why don't you try an experiment of porting one of the smaller projects and have and evaluate how much of a hassle it is? I am willing to bet you will figure out is not that complicated at all.
And now remind yourself that there are self driving cars out there and autonomous digging equipment that is based on ROS, which doesn't have any plan or intent to move to python 3.
Yeah but the general consensus for the core stuff seems to be "we'll do that with 2.0", which at this point seems to
materialize since forever aka. vaporware...
I mean hiring page doesn't mean they actually use it in the product. You can use ROS for designing the system, but in terms of performance it has issues if you try to use it in an embedded context. I still kind of doubt they have it running in their product.
Makeshift solutions last the longest, I'd highly doubt that they run 2 messaging systems side by side, thats just unrealistic for a startup. Especially considering that ROS is very invasive with it's MSG format and build tooling.
Thats not true, you're referencing the ROS wiki page of the MoveIt! Planning package, which has nothing to do with ROS other than using it.
Widespread Python3 adoption is planned for ROS 2 which has been vaporware for the last 3 years.
The transition to python 3 from 2 was rough I’ll give you that. But companies and maintainers have had years and years to either fork and port or altogether rewrite their code for python 3 — the only python that matters.
I liked the stance the post took: it was very matter-of-fact in its tone regarding python 2 support — consultants are there for that and they will charge a mint to give you time you should have taken to move your codebase to python 3.
From my experience, large codebase refactorings are almost never a priority until the deadline is just right there. 10 years for many companies mean the last 6 months, when everyone else has already done a lot of work on the same problems as you will encounter, lots of issues have been already solved, and you can probably find people with the python 3 skill. And last but not least, you will find approvals from management side "this year's the end of support, it must be done, otherwise we are out of security patches". So, essentially yes, they gave a lot of time for enterprise companies to let others do the dirty work :)
That's true. I worked at an enterprisey shop that delayed upgrading from Java 6 before its EOL. By the time they started, the EOL date had passed a few months prior and the upgrade itself was a 1.5 year effort. Some orgs can be pushed, others have to be shoved.
So they are sun-setting it 12 years after having introduced its replacement.
I think there is a parallel with the .net Framework. .Net core is a similar breaking change (not the syntax of the language but very much so in term of core libraries and project types). I wouldn't be surprised if .Net full followed a similar timeline.
In 2015, there was no way I could have moved to Python 3. There were too many libraries I depended on that hadn't ported yet.
In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now.
For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backing it up.
Personal use can be quite different to business use cases. For many companies the conversion can be quite horrific, they might be quite happy to pay for support for older versions.
Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short.
Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now".
If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.
Library, as is most open source libraries out there, sure.
For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.
You're waiting for other people to do stuff, and for many of them 1-2 years is the timeframe when they are likely to start working on it. From that perspective 1-2 years is not "too short", it's the "we intentionally chose this as the optimal time". That doesn't really depend on when the deadline is; if you postpone the deadline, then they postpone the migration - as pretty much every library did back in 2014 when the deadline was postponed by 5(!) years.
Beggars can't be choosers; if your company wants or needs major libraries to have migrated 4-5 years before the deadline, then your company has to participate in making that migration happen. Or accept that it's going to be done later than you'd like, because the needs and motivation of these library maintainers are quite different from the motivation of Python core maintainers.
I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline?
Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if you agree to ship v3 compliance by next month" is not reducing that pressure, it's adding to it.
More programmers != better results or faster delivery. Your solution is just going to create more problems.
You shouldn't take "Do you have programmers?" too literally.
Programmers ~= Resources ~= Money
=> If you want your dependencies to be upgraded in a reasonable time frame, try to contribute to financing the maintainers (or support them in a manner _they_ find suitable).
You fork the library. You fix the incompatibility issues. You issue PRs back to the mainline to help them adopt the same fixes. At some point in the future you can switch back to the main repo if they've migrated, or you can consider that library abandoned and continue to maintain your own or find an alternate.
At no point do you have to wait on anyone else, you choose to.
You can do that, but then they won't accept your solution, so you just spend time developing a parallel system that you need to support yourself until the end of time. Been there, done that.
If there is significant demand for solving the problem your fork solves, others will migrate to it. This is made harder when the main solution gets to squeak along for 10 extra years on a version of the language that should no longer get first-party support. Of course there is going to be less demand for that Py3 solution when there is no immediate consequence for continuing on Py2. Killing security update support for 2 will boost the demand for libraries using 3, and make it more likely that your fork gets merged or becomes the defacto standard.
The Python 2->3 window is an example of where being too nice to too many users harms the project. Once Python 2 is dead, people will choose between being the sole maintainer of a Python 3 fork of some Python 2 library versus a being a sole maintainer of their entire Python 2 stack from the language layer on up.
How are they supposed to migrate if I can't openly host my solution because it was developed on company time? Merging back into the original project is one thing, but making your solution available some other way is a whole other story.
This is the reality of having lots of open source dependencies. Important changes/bugs may exist, and the maintainers are under no obligation to fix them to suit your business needs. If you want them fixed, you contribute to the code base (or fork it) and fix it.
Still better than my last programming job where the vendor of a vital piece of HW had provided a C++ API (also vital), but refused to provide dlls that would work in anything newer than VS2010. At least with open source you can do something about it.
This is dumb. You're blaming people who probably don't get to call the shots. The managers who do have the ability to make different decisions are, themselves, often under the gun to meet other commitments.
Sure, they will have to cope. One of the ways people cope is by accepting security risks and continuing to run with old versions. Another is to decide that Python isn't for them, and move resources toward better platforms with commercial support for older code.
The fact is, that until a few years ago there were too many libraries that were not compatible for most organizations to make the switch. So, effectively the window for those organizations has only been a few years.
There is also the third choice - you don't migrate and keep doing your job (developing features) on the legacy code base. Things like certificates will have ad-hoc solutions pushed whether you like it or not, and the language will keep trundling along.
If there wind up being major security issues, there will be little choice but for someone to take up the mantle and fix them. Because companies aren't going to switch, and when you've got a botnet ravaging the internet they can't flip a switch and do a big-bang rewrite, someone will have to push out a patch for them.
This isn't the end of Python 2, it's just the Python team washing their hands of it. Ask PHP or Cobol users how their attempts to kill legacy codebases worked out for them.
This whole endeavor was complete folly from the Python foundation to begin with. A big-bang rewrite because they didn't like the syntax, and they didn't even fix the GIL while they were at it.
A lot of libraries refused to migrate before Python 3.5(?) came out which was ~4 years ago. IIRC earlier Python 3 versions had performance regressions compared to Python 2.
If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.
Unfortunately, I think this type of thing actually is the case for many organizations. Trying to explain the business case for paying off technical debt to a non-technical person can be very difficult when "right now everything works."
I can really understand that… but I believe that such organizations will experience significantly more problems than just Python upgrades. (I work for one.)
I get this, though: porting code affects all parts of the code base, so it generates git conflicts all the time. It's way more of a pain to do than routine feature development or refactors. It gets difficult to have part of the team work on features while another group works on the port to a new version, because that generates a ton of conflicts. It's easier to get the entire team working on the port.
I had to manage a mature codebase upgrading Ruby versions, and it was painful. And that is fairly mild by comparison; not the big jump from Python 2 to 3.
> Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short.
Is it though? Especially since as late as 2014, everyone was under the assumption that in 2015 security support would end. We were already trying to migrate long before that. The five year extension seems pretty reasonable to me.
Python 2's EOL was first announced in 2008, it was extended in 2014. That's more than a decade of forewarning that this was coming down the line. A decade of Python2 receiving security fixes.
Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.
You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.
But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.
> But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy.
This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
> This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (and many others) have been doing this for years. Just look at the number of packages on PyPI that run, unmodified, on 2 and 3.
I try to write compatible code myself too, and the only reason it's "zero effort" to run in Python 3 is that I've already invested said effort when making it compatible. Getting strings and paths and stdio to be cross-compatible and working correctly in both 2 and 3 can be quite painful in my experience. Which was kind of my point with the vehicle analogy. It requires a significant investment that you're ignoring, and lack of enough underlying support to justify it during that time.
Driving an EV without charging stations is (nearly) useless. You can still run Python 2-3 code with a Python 2 interpreter with no significant consequence.
EV drivers don't need charging stations at all if they have an open plug at home or at work. The metaphor still sort of works that Python developers had plenty of time where maybe they didn't have enough charging stations on the wide open highway roads of Production to use Python 3 there, but certainly could have been happy to use an EV to commute from home (hobby projects) to the work parking lot (side projects, automation projects, new projects) and back while they waited for those "charging stations" to be built.
I don't want to debate the amount of shoehorning necessary to validate the metaphor. We all understand concretely the issue at hand, the metaphor is only obfuscating at this point.
Quick: run a shell command, split up the reply by line, run a regex on each line, and save the results to a yaml file— now, does what you wrote work correctly on both Python 2.7 and Python 3.3+? Yeah that's what I thought.
It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.
No one is arguing that upgrading would be trivial; the argument is that it's necessary work that could have been started 10 years ago. Also, if you run your unit tests on Python 2 and 3, you'll get pretty good pretty fast at writing 2-3 compatible code.
The comment I was specifically replying to asserted that "you could easily write Python 3 compatible code", and could have been doing so 10 years ago.
This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.
Ah, I see the confusion. In this case, "easily" is relative. The assertion "you could easily write Python 3 compatible code" was in response to the (implied?) assertion "you can't do anything to migrate unless your dependencies are migrated". Perhaps "simply" would have been a better word choice than "easily". To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem.
> To your point, writing 2-3 compatible code has a real cost, but to the GP's point, it's the obvious solution to the "can't do anything until deps are migrated" problem
Q: Ten years ago how would you have explained to your manager that you needed your team to start writing 2-3 compatible code, which obviously takes considerably more time and effort than sticking with 2 compatible code?
At this point, all the code I write is 2/3 compatible, and the things that annoy me are all py3 only features. Backwards compatibility stuff is pretty easy. Most of the easy problems are easy, and six has solved all the hard ones for like 7 years.
And I've been writing some of my code 2/3 compatible since 3.4.
import subprocess
import re
import yaml
output = subprocess.check_output(['ls', '-l'], universal_newlines=True)
matching_lines = []
for line in output.splitlines():
if re.search(r'total', line):
matching_lines.append(line)
with open('matching_lines.yaml', 'w') as f:
f.write(yaml.dump(matching_lines))
Nice. Yeah my life got a lot easier when I learned about `universal_newlines` changing the subprocess return type under Python 3.
The much worse case of this that I dealt with a few years ago was reading in and modifying XML files, and then saving the modified XML contents as strings in a yaml file (a keyed cache). The input XML files (which I didn't control) were not consistent about having the encoding marked, and that really made things a mess for ElementTree.
This program would crash with a UnicodeEncodeError upon encountering any file with a non-latin character in its name on Windows with Python 3.5 or earlier.
I know that's not the version of Python you were targeting, and I know you didn't write this program to be cross-platform, but I wrote a similar program and I was repeatedly surprised by those sorts of problems. I don't entirely agree with mikepurvis, but I do feel his pain.
I often hear this, but I just don't see this working in practice. A very similar example I have experience with, I've often worked with people who tried to write code that would be "compatible with Windows" (I primary work in a Linux environment). It makes the code more difficult to read and as soon as you try and run it in Windows it fails spectacularly.
You can write code that's compatible with both Python 2 and 3, but I don't think you can expect to be using Python 2 exclusively and write code that works well in Python 3 unless you're constantly running it with Python 3. Especially, if you don't have much firsthand Python 3 experience. This is much easier if your code is isolated from those dependencies and you write tests that run in both Python 2 and 3, but that's quite a bit more of a commitment than you seem to be implying.
There are a ton of open source projects that have done python 2/3 simultaneously in practice.
I get your point though about not being able to run full integration tests due to dependencies. Still, if you were making a good effort to keep the code Python 3 compliant, it would make upgrading much easier.
Also, my other suggestion- contributing to Python 3 compatibility for modules you depend on! That will give you Python 3 experience :)
It's interesting seeing who the holdouts are, though. Less than a year ago, the CEO of Sentry (the crash reporter) locked a Github thread with essentially "we'll get there when we get there, sometime in or after 2020." But then, as late as 2016 their stance was pretty much that they would never migrate, so I suppose it's not surprising that they aren't super prepared for it:
Calibre is another well known case, and they don't plan to migrate.
Actually, I can't wait to remove it from my hard drive on Jan 1, since it's one of the most poorly designed apps I've ever used. It's really not surprising at all that they're not able to migrate it, assuming the quality of the app is indicative of the quality of the code. I wouldn't be surprised if the same was true of a lot of applications that are refusing to migrate. (I'll probably have to find an alternative to ebook-convert, the command line tool that's the only part of Calibre I use, or maybe I'll rewrite it in Python 3 myself.)
> No, it doesn't [need to convert to Python 3]. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.
The only good part of calibre is the `ebook-convert` commandline tool that has a stupid-simple interface (polar opposite of the gui) and handles all kinds of formats that pandoc doesn't.
The gui, Calibre proper, is a total nightmare. Functional, but my god is it esoteric and ugly. I've heard people actually use that gui as their primary ebook reading software and I just can't fathom how they find that tolerable.
I dislike Calibre main GUI as well. It looks a bit dated and all, but really convenient for downloading books from Userfiction forums like Spacebattles via the Fanficfare plugin. Also good for simple editing of ebook metadata. Built-in ebook-viewer is highly configurable with custom keybindings and themable with custom CSS.This is my setup
Reality? You can maintain an absurd, unintuitive, dated UI by yourself fairly easily, but even someone who pushes out two minor updates per week is going to be taking on a little too much in my opinion if they believe they can also support a fork of a major language.
His responses leave an incredibly sour taste in my mouth. Not only is he obviously short sighted with his "Python 2 is not the past and Python 3 is not the future" but all his responses just sound like someone who got up on the wrong side of the bed. Every morning.
That's a pretty low bar. I still think that move by Apple was pretty terrible. Especially given that it's 100% impossible to downgrade iOS (your last point).
In my mind, I kinda hope that data they used to back this decision up was asking "Hey, all you other volunteer Python language devs? How many of you want to work on the old Python2 codebase still? How many of you would prefer to be working on Python3? OK, that's just about unanimous. How about we all get drunk on Newyears and shut it down on Jan 1st?"
You can still get Microsoft Windows XP support today. If you're prepared to pay enough.
I wonder how many of the people who're upset by this have ever or ever worked for companies that've ever sent anything more than pocket change to the people Python?
> For my personal use case at least, this timeline worked out well for me.
Hint for Hacker News commenters: 99% of the time, if your phrase includes the term "use case", you can safely just delete it and lose no meaning. It's just a way to say "for me" or "for them" that sounds more technical but really isn't.
In this case, you could say "This timeline worked out well for me".
I don't necessarily think you're wrong, but HN has a history of comments like this that criticize other comments and add nothing to the discussion. Mine is another example, but since you got the ball rolling I figure I might as well chime in.
I think the grandparent's usage of "use case" was totally fine. It wasn't distracting and it didn't change my reading of that comment in any way, shape, or form.
> HN has a history of comments like this that criticize other comments and add nothing to the discussion
I disagree. HN is a place that seems to pride itself on the quality of its discussions, and on a higher intellectual caliber when compared to other Internet discussion venues. Surely a good command of language is part of that?
Yes, it does pride itself on the quality of discussions. It also has done that just fine using the voting and flagging mechanisms. When I see comments criticizing others' comments I am always reminded of reddit. I think this is exactly what you're hoping to avoid when you come to HN.
Beyond that, who are we to judge what constitutes "good command of language?" Which language are we even talking about here? I don't think HN is going to become a better place by becoming more elitist.
> When I see comments criticizing others' comments I am always reminded of reddit. I think this is exactly what you're hoping to avoid when you come to HN.
> I don't think HN is going to become a better place by becoming more elitist.
Come on now, don't be disingenuous. Of course they are mutually exclusive, because you mean "not being reddit" as in "we are better than reddit" -- an elitist stance.
I said I was done but I have to respond to this. Reddit prides itself on tangents and bickering and jokes. It’s great. I love Reddit. But I come to HN for focused technical discussion. I don’t believe one is inherently better than the other. Therefore, I believe it is not mutually exclusive.
To me, "for me" and "for my use case" mean subtly but genuinely different things.
"For me" highlights the fact that my preferences, character, skills, etc., are different from other people's. Something might work well for me but badly for someone else because I happen to be good at working around its quirks, or bad at noticing its faults, or just not interested in the things it doesn't do.
"For my use case" highlights the fact that the things I need to do are different from other people's. Something might be good for my use case but bad for others' because I don't need very high performance but they do, or because I need the gostak to be able to distim the doshes backwards but they don't.
If I move on to doing different work and someone else takes my place, I expect something that works well "for me" to continue being useful for me but not for them, and something that works well "for my use case" to be useful for them but not for me.
Corparate-speak that makes its way into common language is frequently justified post-hoc by subtle differences in meaning like the ones you allude to. The problem is that these differences are personal and subjective. Ask someone else, they might have a different answer. I have had the same discussion multiple times over the equally meaningless and inelegant "going forward".
Corporate-speak and cliché idioms makes one sound less clever, not more. It might temporarily signal belonging to some crowd (for example, the HN tech crowd), but in the long term it hampers one's ability to communicate in an effective and elegant way.
This seems extremely pedantic. "Use case" as it's used today basically just means "case" or "situation" for a particular project or task or goal (edit: and for a particular individual/group/entity/organization). It's not business jargon or a buzzword term, even if perhaps it started off that way many decades ago.
I can think of countless annoying corporate buzzwords I see all the time on HN or at my job which are totally opaque and useless. "Use case" is two simple English words which anyone, including non-tech people, uses and clearly understands. This is not the hill to die on. I could link so many comments posted in the last week which are infinitely more buzzword-laden and irritating. If you really feel the dire necessity to chastise them, at least pick one of of those.
I do partly agree with you on "moving forward" or "going forward". I'm skeptical the situation was nearly as ambiguous as you suggest (it means "in the future", which is ambiguous, but it's no more ambiguous than saying "in the future", and anyone can easily request clarification if they hear "in the future"), but I had a few managers who said and wrote that like 30 times per day, and it does start to get on your nerves. Perhaps "use case" is similarly overused by some, but it also has a specific and clear meaning which would take longer to say/write than just using the term.
> This seems extremely pedantic. "Use case" as it's used today basically just means "case" or "situation" for a particular project or task or goal. It's not business jargon or a buzzword term, even if perhaps it started off that way many decades ago.
Notice that you are already in contradiction with the first criticism that I received in this thread, where a subtle difference in meaning was proposed.
> it means "in the future", which is ambiguous, but it's no more ambiguous than saying "in the future",
The main point is that it is totally unnecessary, we already have the future tense to talk about what will happen in the future.
The same applies here. Remove the phrase with "use case" and you get exactly the same meaning, with less words and less cringe.
I see your point, but I think it's only redundant if the context of the use case(s) has already been established, in which case you can just refer to the thing itself (directly, or with demonstrative words). If anything, I think the much more redundant and cringey part is the "personal" in "my personal use case". "My use case" sounds fine to me.
"My use case" just generalizes "my {project, job, task, case}(s)". It's not ambiguous, because the intention is to be general. "For me" is a bit more general than that, though, and sometimes you want to be a little more specific.
The specificity hierarchy / subtle difference in meaning goes from "for me" (my attributes) -> "my use case" (my attributes + the case's attributes) -> "my [job/project/whatever]" -> "my [exact thing I'm specifically doing]". I think all can be valid, depending on the context. I maybe should've said "'case' or 'situation' for a particular project or task or goal done by a particular person (or group or organization)" instead (I was implying the latter part), but there's no contradiction here. By contrast, "moving forward" is typically implied and unnecessary no matter the context and can usually be cut as dead weight.
> "Use case" is two simple English words which anyone, including non-tech people, uses and clearly understands
Source?
Where I am "use case" is definitely [still] tech jargon. I know very very few non-tech people who've ever heard it used, much less could give a definition for it.
You're picking much too fine a nit here. The OP's use of "personal use case" is not a distracting example of corporate speak. I knew exactly what he meant when he wrote it, and his usage did help to clarify that he was basing his statements on his use of the technology, and not on his personal feelings about it.
But if if this is a hard-stop item for you at this juncture, then we should circle back... I'm sure we can align on this going forward. ;)
I don't know... I don't really consider myself part of the HN echo-chamber (who does, I guess?). I hear "use case" fairly regularly here at our university, among non-technical staff in our academic support units. Perhaps we've indoctrinated them over the years...
Regardless, I would argue that "use case" has a quite specific and useful meaning that goes beyond mere corp-speak. I wouldn't use in conversation at a neighbourhood barbecue, but in a technical context (like a discussion of Python) the usage seems perfectly fine.
I dunno -- if we're going to focus on the tics and quirks of the HN echo chamber, isn't this level of bikeshedding over the term "use case" kind of peak HN? :)
> Corparate-speak that makes its way into common language is frequently justified post-hoc by subtle differences in meaning like the ones you allude to.
You seem to have reversed cause and effect here. New words/phrases/jargon comes into common usage when it is useful for communicating something. The difference might be subtle, but people wouldn't use the word if they didn't think that it was an important distinction to make.
Hint for Hacker News commenters: 100% of the time, if your comment includes grammar or style advice, you can safely delete it and the discussion will lose no value. It's just a way to say "I'm smart" or "look at me" that sounds helpful but really isn't.
Wouldn't Java 1.0 code still work in Java $LATEST even with modules? As i understand it the question was about keeping stuff working, not refusing to add new stuff.
1.1 is what would still work. There was not much Java 1 code in existence.
Java 1.4 to 5 was annoying and the last release to introduce a lot of source code in compatibility. Which was sometime in 2004. Modules is mostly figuring out what switches to set on startup, not so much refuses to work.
Perl5 is not being EOL'ed in favour of Perl6. When the time does come around for Perl5, I would guess that only a small fraction would migrate to Perl6.
"Built for", probably not. "That guarantees support for", some Windows releases and Microsoft stacks ended up doing more or less that, be it by accident or strategy. Probably some mainframe-related stuff too, being the only sort of thing around before the late '80s and possibly still in use.
There is also the case of Oracle, which defines support as "you can read our knowledge base and we will answer a phone before telling you it can't be done", meaning their support is literally for life (of the company). And they still manage to screw it up by deleting old KM articles...
Everything else in IT goes towards shorter and shorter support windows, because the field is always in flux and change (or rather churn) accelerates every year.
I think there are plenty of programming languages (maybe even most of them?) which take backward compatibility as a very serious goal. Obviously there's a balance between "don't break user space!" and fixing major problems (e.g., C's gets()), and most of the major ones seem to lean toward the former.
At the company I work at, we've got a large amount of Fortran code from the '70s that works fine with the latest and greatest Fortran compilers (barring deprecation warnings which help guide refactoring efforts). Same with C/C++ from the '80s.
Common Lisp code tends to be very stable long term. Occasionally people dig out some old code from the 60s or from really old books and papers and it will just run on modern systems. Maybe with slight modifications since the standard was finalized in 1994 and there were some changes to the way scope works in common lisp compared to say the older mac lisp, but anything written since that is written in portable standard compliant common lisp is pretty much guaranteed to continue working while there are still people willing to maintain common lisp compilers for whatever hardware exists in the future. It's actually extremely comforting to be able to come back to a project after not touching it in a few years and have every test pass even if I upgraded all the dependencies(as long as I picked the right dependencies that is :), lispers tend to be pretty conservative about breaking changes in mature and popular libraries.
Excel spreadsheets, which contain an astonishing amount of business logic, tend to be backwards-compatible far longer than the OSes that Excel itself runs on.
Many compiled languages might have breaking changes at the language level but are still compatible at the dll/binary level. Java 1.0 and C# 1.0 code can still be compiled and run on modern JVMs and CLRs, and rust 2015 and 2018 work together as well.
Every now and then a language like no other pops up: it's use is unusual and unusually long. Various biblical languages come to mind: Latin, Church Slavonic, Hebrew at one point. These languages are feature complete, and the fact that they didn't change was their main appeal.
I've always thought Python 2 might be headed for the languages. Which is fine, it's great to have a programming equivalent of Latin.
... I'm sorry, but wouldn't the Latin equivalent be C... given Python is written in it, and most languages syntax is born from it.
Python is more like the English language... it's borrowed a bunch of stuff from many different languages and isn't even compatible with itself ;) (2 vs 3).
I mean, this is assuming with thing spoken languages are even at all similar to programming languages... which I don't think they are.
Python 2 sees new code all the time too. It's not dead! That's the whole point, it can simultaneously not see any new changes but still be used by those who value the absence of change.
> Hebrew was completely replaced with modern Hebrew and gets new changes constantly.
Just to clarify further, modern Hebrew is mostly backwards compatible with biblical Hebrew, it's not an entirely new language. It was mostly updated in terms of vocabulary that was necessary for the modern era, plus some spelling/grammar changes.
Modern Hebrew speakers are able to read biblical Hebrew almost completely, though there are some differences (think of English speakers reading Shakespeare - though even less difference than that.)
Sounds like Python 3 (Modern Hebrew) vs Python 2 (Biblical Hebrew), no? Anyone who can read Python 3 should barely struggle at all with Python 2. Anyone who can read Python 2 will see a few tweaks in the grammar / functionality (“vocabulary” in this analogy), but mostly straight forward.
Funnily enough, Latin became relatievely stable because people stopped using it outside the Church. After the fall of the Rome it quickly transformed into French, Spanish, Italian etc.
The battle has not over yet.
RHEL 8 has Python 2.7 in their Application Streams.
So looks like Red Hat will provide security updates until Jun 2024
https://access.redhat.com/node/4079021
There was some mention somewhere that RH will support the python 2.7 appstream for RHEL 8 as long as RHEL 7.x is supported. Which coincidentally is June 2024, so, yeah.
"What will happen if I do not upgrade by January 1st, 2020?"
"You will lose chances to use good tools because they will only run on Python 3, you will slow down people who depend on you and work with you."
The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right now as they're reading it. But instead, it seems the author simply wanted to convey how sick they are of Python 2. The author does not appear to understand their users; that's their real frustration.
In life outside of Python... The transition in C/C++ from C++98 to C++11 and then C++20 (and beyond) has been quite clean and professional. There were some glaring issues with C++11 that later got patched up (e.g. rvalues but no optional, no filesystem, make_unique, etc). Most importantly, compiler support and standard distributions improved a lot. There were often clear incentives to upgrade, and it was relatively easy to stick to an old standard where necessary.
I think the Python community has failed to present strong enough incentives for upgrading to Python3, and that's why users are sticking to Python2 and 'slowing everybody down'. The jump to C++11 was obviously needed: at the very least, `auto` saved much of your sanity and you no longer really needed to include Boost in your build. But you could stick to an old standard if you wanted; you could even transition a codebase module-by-module in some cases.
The Python3 community seems to have been groping for a similar killer feature (e.g asyncio, as discussed in Amber Brown's talk above), but the value-add isn't so clear. `six` is honestly a nice catalogue showing how many changes in Python3 are largely sentimental.
Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
> The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right now as they're reading it.
If people haven't found reason in the last ten years, then they aren't about to be convinced today. All the arguments for and against have already been widely discussed, and that the EOL of Python2 is here should come as a shock to exactly no one.
There's no reason to re-hash over and over what is already out there.
Don't quite unterstand the downvotes. Meanwhile the language and more important the entire infrastructure is affected: python vs. python3 switches pollute virtual environments, deployment, whole systems scripting code, bindings, derived code and more. This is not 'a bit'. Ending this situation is, as already mentioned, a (big) incentive.
Totally agree, there's some degree of arrogance, especially in that section of the article. Maybe it's unintended, developers are not always good at PR.
Me too. Anyone who's running 15+ year old free software which came with 6 or possibly 12 years of notice to upgrade to the new version (depending on how you count it) and is complaining that it's no longer going to be supported for free by someone else, is being quite amazingly arrogant...
Maybe it's unintended, users of free software are not always good at being gracious.
Yes, those people are arrogant and/or entitled, but you know darn well that's not the arrogance GP was talking about.
It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
As choppaface said,
> Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided. I love Python and I love GvR, but he stumbled badly here IMO (not as badly as Perl 6, but that's small comfort) by trying, in effect, to cannibalize 2 for 3. I don't enjoy saying this.
I've met GvR briefly and he didn't seem arrogant at all to me. But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
> It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
That's a strange way to characterize "decide to no longer volunteer their own time." And by strange, I mean rude. If you want somebody to spend their time maintaining python2, why don't you cough up the cash?
They are also telling everyone that, once they stop volunteering, Python 2 is dead. They insisted that the Tauthon project rename itself. It's one thing to say, "we won't support it", it's another thing to actively try to kill it, especially when they know people are still using it.
Making them use a name other than python is hardly any great hardship. Mozilla maintains their trademark too and nobody whines to hard about that. Just call it "boa" or something. Firefox->Icecat.
> Making them use a name other than python is hardly any great hardship.
It wasn't. (And Tauthon is arguably a really cool name.)
But it does indicate that they want Python 2 dead.
> Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them.
Like I said, if people were just fading out of Python 2 that wouldn't make me call them arrogant, it's when they insist that other people have to ditch Python 2 that I start to feel like there's some arrogance there.
Like I said in a another comment, the only thing you get from switching to Python 3 is Python 3 compatibility. If Python 2 remains viable (which it will) there's much less incentive to use 3.
Python 2 isn't broken or bad or anything, it's just not Python 3. We aren't being urged to switch because 2 is (so much) worse than 3 but because it's a viable competitor to it.
Okay, but then what do they get by avoiding brand dilution?
Look, I'm not really interested in proving that so-and-so is arrogant or not.
It's pretty clear to me that some people have some animosity to continued use of Python 2, and I find some of the language and attitudes smack of arrogance. I'm arrogant, and it takes one to know one, eh?
But I don't have a magic arrogance-o-meter so really what are we arguing about? Our feels?
Arguably, your reference upthread to the Perl5/6 problems makes it a more than reasonable request that the trademark "Python" doesn't get confused in the minds of users by awkwardly referring to 2 different and incompatible languages, however tightly they were related a decade ago.
Perhaps you could argue that the Python3 language could have changed it's name and "left" the trademark and reputation behind for some other random people to take over. But a stronger argument would be that the reputation Python has earned over the last two decades "belongs" to the ongoing team who built and supported it for way longer as version 2.X than they needed to and who've now been releasing it as V3 for over a decade.
If "people are still using" Python2, nobody is going to stop them. Nobody it deleting all the copies of the source code to Python2.7 or revoking any of the rights the granted when it was released:
"PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version" (from: https://github.com/python/cpython/blob/2.7/LICENSE )
It you're uptight because the PSF owns and protects the trademark to the name "Python" where used in relation to a programming language _that they wrote and gave away and granted you extensive rights to do whatever you damn well please with their source code_ - that's a totally unreasonable expectation on your part.
Spend two decades building your own reputation for intelligent and responsive language design and stewardship, then walk away from all that reputation by allowing random people to piggyback off it, then get back to me and tell me how that's actually how shot should work... Guido and his team have put the hard yards in. They've given you pretty much free reign to do whatever you like with their source code. They are not only under no obligation to allow you to call what you do with that "Python", but they arguably have a responsibility to ensure that people who expect a historical level of stewardship and "benevolent dictatorship" of the language called "Python" are not mislead by people other than them using that name to continue to promote old and discarded technology and design decisions with any assumption that those new people deserve any of the historical reputation that "Python" implies.
Get over the "Wah! I can't use the name Python! I'm being oppressed!!!" childishness. I, for one, do not want _you_ specifically, and people like you in general, to fraudulently trade in the reputation that the Python trademark would bestow on your work if you were allowed to call it "Python".
In what way is "we are no longer going to provide any of our volunteer time to support Python2" even _vaguely_ able to be characterised as "grabbing it out of the hands of people still using it"???
Join the other 11.5k people who've forked it on Github, and an unknown number of people who've cloned it without playing Github's high-school popularity contest...
Nobody is ever going to take anything Python2 related away from you.
There's a lot of talk here about "arrogance", all from people upset that some other people have decided not to do any _more_ free volunteer work on a thing they've been trying to get people to upgrade from for 3/6/12 years depending on how you count it. Those people complaining about "arrogance" are putting words into the mouths of the people who've done so much free work for them over th=e last 20 years, accusing them of saying "fuck you" and of "grabbing things out of the hands of people" and of "cannibalising" the code they wrote 15-20 years ago while providing newer better code (which happens to not suit some people who're not prepared for whatever reason to update their own code).
GvR is _not_ the one seeming arrogant in this thread...
(And didn't the last line in my comment you replied to make it abundantly clear I knew exactly what arrogance the OP was incorrectly claiming, and what the actual arrogance on display was?)
> It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
No one is doing that. Python 2 is available, open-source software. The Python core team discontinuing development isn't grabbing it out of anyone's hands. Open source projects whose core teams have discontinued them in favor of an incompatible (either technologically or by licensing) alternative, or abandoned them altogether (or just not maintained them in a way that pleased the community), have often had maintenance picked up by alternative maintainers, who have often had to use alternative names for the independent continuation project. Nothing is taken out of anyone's hands by this.
> If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided.
And we all saw how well starting with that goal worked for Perl 6.
> But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
No one has that attitude (except maybe employers, but that's more about a desire to continue to get paid for using Python 2 than merely to continue to use it.) You are perfectly free to continue using Python 2 until the Earth is swallowed up by the Sun and no one will stop you, or even really care.
Did we read the same document? It seems fine and a perfectly normal explanation of what’s going on and why, like any software with a defined lifecycle would have.
I guess it depends what lens you are reading it through. If you're used to reading documents from open source projects it seems perfectly normal. If you're used reading documents from Oracle and SAP explaining changes to their long term support contract, then this will sound completely alien.
The tone is excessive and over-the-top because it's the last of numerous documents over the years saying essentialy the same thing. And yeah, they are probably sick of supporting Python 2 because a few vocal users still complain a decade after the writing is on the wall.
There are tons of incentives to upgrade, but unfortunately very few to none can be considered killer features, and thus are harder to show off in a concise reminder about the sunset.
You have to give it a try and actually use Python 3 features to realize how much this improves your life as a developer.
Python 3 isn't perfect, but especially with later versions, it's a hell of an improvement over Python 2.
> The tone in this document is excessive and over-the-top.
No, the quoted passage is exactly correct. Many major tools have dropped Python 2 support, and others have put that on their timeline. If you continue to stick with Python 2, you will lose out on the ability to use an increasing number of current tools, because the community is moving on. Relaying that fact isn't arrogant.
While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it.
As an aside, a few weeks ago I interviewed at one of the top 5 investment banks for a software engineering role to maintain one of their main trading systems, written entirely in Python 2. My first question was what their plans were in porting what they called "one of the worlds largest Python 2 code bases," and it was "on the roadmap".
Surely the Python core team are aware that teams like this exist in some of the largest companies in the world, and I assume they've had at least some level of dialogue with companies like this to say "we're super serious this time, we're about to stop support for Python 2", or something along those lines?
Maybe it's a blessing in disguise that I was rejected?
I've never worked for a company of that scale, so I don't know how hard it'll be to find legacy developers, but I imagine it'll take at least several years to port a public-facing system to Python 3, if they were to start now.
If they start in the next few years, I imagine it'll be much harder to find ready and willing Python 2 developers with the experience to navigate such a big code-base? They could hire consultants, but I imagine the future hiring cost will also be astronomical.
Well Python 3 came out in 2008, this date is known since 2014. If they start in the next few years, yes you'd expect it to be expensive.
But distribution vendors like Red Hat and Ubuntu have Python 2 in long term support distributions that they will give support for a few more years, so it is possible to use those. And after that they offer more years of support to paying customers. It's not necessary to hire programmers to do this for the companies needing support themselves.
You can count your blessings. I think I know what company you’re talking about, and as far as I know they have no inclination to ever port anything. It’s the sort of company with enough money to pay to have their own runtime, simply because it’s organisationally easier to throw money at “maintenance” once established, than it is to do a big port or rewrite. Legacy support is a well-paying job, if depressing.
> I'm still surprised that it's taken this long to finally close support
That's because the Python community is too nice.
When Ruby or node broke compat, they just said "move or die". People moved.
When Python broke compat, they gave 7 years. People screamed, cried, complained, sweared it was impossible for them, that life was hard and the PSF was unfair.
They got an extension of 5 more years.
People still complained !
Hell, famous authors resented python 3 for years, refusing publicly to update their book.
On the other hand, the PSF had a very small budget, only few tiny donations and contributions by people or big companies that were saying they couldn't migrate that their lines of code. The same code that were making them a living, from a 25 years old amazing tech given to them for free.
My take on this is that if you are doing an open source project with a lot of volunteer work, don't be too nice. People have a tendency to abuse it. Save yourself trouble, and balance respect with users and convenience for you.
Something about the "too nice" thing rubs me the wrong way. You gotta respect the people who develop the software. At the same time, the way people are deemed "complainers" reeks of contempt for the users. Yes, the users sometimes take your free work for granted. But you offered it. If you don't like the expectations that users assume are attached to it, you should say so upfront so they can become entangled with Ruby instead.
I don't think I disagree with your point in practice. Maybe in some details. I just don't think that not being credible in your plan to drop support on a given date is necessarily such a "nice" thing to do. You could say it's a "weak" thing to do. It doesn't help people prioritize the move and eventually hurts people by putting them into a jam on the day finally comes here. I think the ideal thing would be to break compatibility piece by piece, assuming it's really necessary, but be _understanding_ about it. Tell people "we understand that this is inconvenient for a certain number of people but have to cut it off at some place", not "stop complaining about free stuff".
> When Ruby or node broke compat, they just said "move or die". People moved.
Unless I'm missing something, this is a pretty disingenuous comparison. Ruby and Node breaking changes have been fairly small, Python 3 was anything but.
Nope, not JP Morgan, although I did interview with them too and they talked about some of their Python systems and how they were currently in the process of porting to Python 3.
I won't name names, but they're also in the top ten and based in America.
> I'm still surprised that it's taken this long to finally close support. ... I interviewed at one of the top 5 investment banks for a software engineering ... My first question was what their plans were in porting ... it was "on the roadmap".
> Surely the Python core team are aware that teams like this exist in some of the largest companies in the world
Why would you assume they considered their users? Maybe they went purely for some abstract purity with tenuous benefits and didn't actually speak to their stakeholders. Remember, the "D" in BDFL stands for "dictator".
Although their package management requires manually specifying the minimum accepted Python version for every single package, so they have thousands of packages that would run just fine on Python 3.7 but no one has the time to manually check and label them as such. So their default is still 3.6 and using 3.7 as your default version is not well supported.
I wish someone told me Gentoo is a non-starter before I wasted an afternoon installing it.
While we're on the topic, it's pretty stupid how PEP 394, the one that says "python should point to python2.7", gives its reasoning as "because all Linux distros except Arch do it this way" and then all the distros say "python should be python2 because the PEP says so" for the next 9 (maybe more) years. How is anything ever supposed to change?
We are volunteers who make and take care of a Python2 fork with backwards-compatible Python3 features. That means we will keep on improving it without breaking your code base or forcing you to hire the language creator and spend more than 3 years porting your code to Python3, with no actual business benefits.
May be I didn’t noticed it. Pretty comfortable use it on python3 in my environment. So, from my point of view, authors of the TensorFlow just need to update documentation to complete transition.
732 comments
[ 2.6 ms ] story [ 308 ms ] threadWell, 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...
Python 2.7 was released 1 decade ago. That's quite a long transition time.
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.
Not everywhere had that foresight.
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?
Now many important libraries have already moved to being Python 3 making the whole Python 2 ecosystem feel frozen.
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.
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?).
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.
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.
Excellent point, conceded.
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.
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.
It still requires dialect selection: https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/C-Dialect-Optio... http://releases.llvm.org/7.0.0/tools/clang/docs/UsersManual....
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...
But I digress... :)
I'm sure people wouldn't gladly accept C code written for a 47-year-old compiler today.
The current standard languauge is C18.
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.
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)).
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.
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.
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"...
The Python foundation is threatening to sue anyone continuing something called Python 2, or even a similar name.
Finding volunteers who are willing to get sued to work on Python will be hard.
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?
I 100% agree. I was just responding to the parent post.
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.
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.
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.
[1] https://www.naftaliharris.com/blog/why-making-python-2.8/
[2] https://news.ycombinator.com/item?id=13147972
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?
> 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?
I know this has come up at least three times I've seen, but I'm having trouble finding them all. Here's one:
https://github.com/naftaliharris/tauthon/issues/47
In this case there was plans to call something py28, to which Guido replied "OK, bring in the lawyers".
""" 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). """
---
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.
[1]: https://en.wikipedia.org/wiki/Pathfinder_Roleplaying_Game
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.
https://en.wikipedia.org/wiki/CPython#Distribution
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
[1] https://github.com/naftaliharris/tauthon
(Unlike other forums, banned users can still post, but their posts require someone with showdead on to vouch for it before it can be seen).
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.
[0] https://www.phoronix.com/scan.php?page=news_item&px=RHEL-8-N...
[1] https://access.redhat.com/support/policy/updates/errata#Main...
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.
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 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...
Workstation: https://access.redhat.com/documentation/en-us/red_hat_enterp...
Server: https://access.redhat.com/documentation/en-us/red_hat_enterp...
Search for "python"
> 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.
People getting paid to work on Python (like at Red Hat) are not considered volunteers.
> 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.
[1] https://discuss.python.org/t/official-list-of-core-developer...
`PSF` should be inserted before every occurance of the word volunteer in that page.
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?
Google has flat-out stated that they will continue to support 2.7 in App Engine for an undefined period of time.
Amazon has inferred through their Amazon Linux 2 LTS support page that Python 2.7 is included in that support for 3 more years.
Boring work though
[1] https://www.hostgator.com/help/article/what-software-and-pro...
Like Google App Engine lol. GAE Standard Environment doesn't support Python 3.
Python 2 is part of the first generation runtimes, python 3 is part of the second generation runtimes. They are not out of the box compatible, even if your python code works on 2 and 3. The first generation runtime included many APIs that are simply just not available in the second gen (you need to build them yourself). See link for more info.
https://cloud.google.com/appengine/docs/standard/runtimes
GAE has been a favorite of mine for years, but now they seem hellbent on ruining it, and I don't understand why ='(
(On the plus side, other things are improving and Run looks good)
[1]: https://softwarecollections.org/
https://news.ycombinator.com/item?id=16808998
We knew in April 2014 that Python 2 was EOL in 2020.
Doesn't mean we should do anything except laugh at their incompetence (or perhaps be impressed by their ability to monetise other people's incompetence...)
Much respect. That’s retro-cool.
(And no, I'm 100% not offering to do any of the work required to make that come true... ;-) )
Latest version of the COBOL standard is COBOL 2014 (AKA the same year python 3.4 was released).
It seems a bit wrong to surprise a customer now.
I fully support them in this. Either you support it right, or you abandon/sunset it clearly.
If someone else wants to step up and do the work, they can always do that on their own.
By the way this is market opportunity that HN readers might consider. If you think you can make money supporting Python 2, then start working. Who knows it could be a gold mine.
The latest official COBOL spec is COBOL 2014 and there are at least two or three competing companies out there that will happily sell you up to date COBOL tools and compilers. So while COBOL may be old, there are still new 'exciting' things happening in the COBOL space.
Out of interest, does anyone know if new COBOL specs add any major language features or are they just low-profile security fixes and things.
I know many of the big ones are already on 3.x for a long time, but I wonder how long will it take to replace and upgrade all the small ones if it did not happen already...
BTW I don't know how necessary was to break compatibility between 2.7 and 3, the pain of this transition comes from that decision
It should be pointed out that Python 2 will continue to be used, and be usable. It just won't get new security upgrades or features. I do not know, but I doubt if there will be a feature or security flaw come up soon that "forces" existing python 2-only libraries to update
EDIT: I see now that they mention that 2020 has been the plan since 2014, which seems reasonable.
https://news.ycombinator.com/item?id=7581434
https://news.ycombinator.com/item?id=7372913
That's more than 10 years ago that the intention to sunset python2 at a specific date was announced.
Anybody who, after 2008, started new, serious python2 projects that were supposed to have a life expectancy beyond a few years was rather "optimistic", and anybody who did after 2015 was almost callous, especially if you "played" with other people's money.
Q) I like Python 2. Can I take over Python 2 maintenence?
A) NO. Try it and we'll sue you.
I'm sure there is a great market opportunity for some developers to do the migrations, or to alternative do backporting for some large companies not interested in mingrating.
(I've definitely seem other cases, but I can't find them). Here is someone wanting to call something 'py28', and Guido replies "OK, bring in the lawyers".
Why would you write a statement that is so demonstrably false?
Q) I like Python 2. Can I take over Python 2 maintenence?
A) Sure. Just don't pretend to be us; call your fork something other than Python 2
To be honest, the whole “Python on other runtimes” movement, as a concept, is more or less over. It’s just too much effort for too little reward, now that CPython has good libraries for pretty much anything you can think of.
Fun stuff...
And I think Audi is using it for their self driving cars...
https://www.builtrobotics.com/
https://discourse.ros.org/t/versioning-roadmap-moveit-1-0-re...
I liked the stance the post took: it was very matter-of-fact in its tone regarding python 2 support — consultants are there for that and they will charge a mint to give you time you should have taken to move your codebase to python 3.
I think there is a parallel with the .net Framework. .Net core is a similar breaking change (not the syntax of the language but very much so in term of core libraries and project types). I wouldn't be surprised if .Net full followed a similar timeline.
In 2019, I feel pretty confident about using Python 3, having used it exclusively for about 18 months now.
For my personal use case at least, this timeline worked out well for me. Hopefully it works out for most everyone. I can't imagine they made this decision without at least some data backing it up.
Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.
Library, as is most open source libraries out there, sure.
For a big company-internal Python codebase that also has to wait for all the major libraries to migrate first, that time frame can quickly shrink to 1-2 years, which is very little.
Beggars can't be choosers; if your company wants or needs major libraries to have migrated 4-5 years before the deadline, then your company has to participate in making that migration happen. Or accept that it's going to be done later than you'd like, because the needs and motivation of these library maintainers are quite different from the motivation of Python core maintainers.
“The free libraries we chose to depend upon haven’t migrated.”
Do you have programmers?
“Of course.”
Put them to work.
“We have other priorities.”
Well then. Your choice, your outcome.
I'm supposed to go and tell all the various projects that I depend on that they have to change their upgrade timescales to suit mine? Even if I had enough time to help them all meet that kind of timescale, why would they agree to fit their changes into my required deadline?
Maintainers are under a lot of pressure. Having users come along and say "we'll add 50 developers to your project if you agree to ship v3 compliance by next month" is not reducing that pressure, it's adding to it.
More programmers != better results or faster delivery. Your solution is just going to create more problems.
Programmers ~= Resources ~= Money
=> If you want your dependencies to be upgraded in a reasonable time frame, try to contribute to financing the maintainers (or support them in a manner _they_ find suitable).
At no point do you have to wait on anyone else, you choose to.
The Python 2->3 window is an example of where being too nice to too many users harms the project. Once Python 2 is dead, people will choose between being the sole maintainer of a Python 3 fork of some Python 2 library versus a being a sole maintainer of their entire Python 2 stack from the language layer on up.
Still better than my last programming job where the vendor of a vital piece of HW had provided a C++ API (also vital), but refused to provide dlls that would work in anything newer than VS2010. At least with open source you can do something about it.
Sure, they will have to cope. One of the ways people cope is by accepting security risks and continuing to run with old versions. Another is to decide that Python isn't for them, and move resources toward better platforms with commercial support for older code.
The fact is, that until a few years ago there were too many libraries that were not compatible for most organizations to make the switch. So, effectively the window for those organizations has only been a few years.
I think he's blaming organizations, not engineers.
I also think organizational dysfunction is a problem that isn't a technical problem that the Python project has the capability or duty to solve.
No one is doing that.
OTOH, it's not PSFs job to protect developers from bad management.
If there wind up being major security issues, there will be little choice but for someone to take up the mantle and fix them. Because companies aren't going to switch, and when you've got a botnet ravaging the internet they can't flip a switch and do a big-bang rewrite, someone will have to push out a patch for them.
This isn't the end of Python 2, it's just the Python team washing their hands of it. Ask PHP or Cobol users how their attempts to kill legacy codebases worked out for them.
This whole endeavor was complete folly from the Python foundation to begin with. A big-bang rewrite because they didn't like the syntax, and they didn't even fix the GIL while they were at it.
Personally, I would guess that many organizations will be running in Python 2 for at least parts of their codebase come 2020.
A lot of devs like to not worry about new things.
I had to manage a mature codebase upgrading Ruby versions, and it was painful. And that is fairly mild by comparison; not the big jump from Python 2 to 3.
Is it though? Especially since as late as 2014, everyone was under the assumption that in 2015 security support would end. We were already trying to migrate long before that. The five year extension seems pretty reasonable to me.
Were I a commercial customer, and had been told to switch to the new version ten years ago, then it's on me if I still have started the migration yet.
This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...
While car analogies are notoriously bad, it's much more like "I'm going to buy a plug-in hybrid and use gasoline until charging stations are widely available". You can write code that works in Python 2 that takes zero effort to run in Python 3. I (and many others) have been doing this for years. Just look at the number of packages on PyPI that run, unmodified, on 2 and 3.
[Edit: gas -> gasoline]
It's still hard to get bilingual Python correct today, and it was considerably harder before 3.3.
This is simply untrue— there are a dozen small stumbling blocks that mean that writing bilingual code has a real cost. And it's not as easy as just having the right CI setup, especially if it's ten years ago and most of your dependencies haven't migrated.
Q: Ten years ago how would you have explained to your manager that you needed your team to start writing 2-3 compatible code, which obviously takes considerably more time and effort than sticking with 2 compatible code?
At this point, all the code I write is 2/3 compatible, and the things that annoy me are all py3 only features. Backwards compatibility stuff is pretty easy. Most of the easy problems are easy, and six has solved all the hard ones for like 7 years.
And I've been writing some of my code 2/3 compatible since 3.4.
Python 2.7: https://repl.it/repls/OrchidDirtyNotification
The much worse case of this that I dealt with a few years ago was reading in and modifying XML files, and then saving the modified XML contents as strings in a yaml file (a keyed cache). The input XML files (which I didn't control) were not consistent about having the encoding marked, and that really made things a mess for ElementTree.
A taste: https://github.com/ros-infrastructure/rosdistro/search?q=utf...
I know that's not the version of Python you were targeting, and I know you didn't write this program to be cross-platform, but I wrote a similar program and I was repeatedly surprised by those sorts of problems. I don't entirely agree with mikepurvis, but I do feel his pain.
You can write code that's compatible with both Python 2 and 3, but I don't think you can expect to be using Python 2 exclusively and write code that works well in Python 3 unless you're constantly running it with Python 3. Especially, if you don't have much firsthand Python 3 experience. This is much easier if your code is isolated from those dependencies and you write tests that run in both Python 2 and 3, but that's quite a bit more of a commitment than you seem to be implying.
I get your point though about not being able to run full integration tests due to dependencies. Still, if you were making a good effort to keep the code Python 3 compliant, it would make upgrading much easier.
Also, my other suggestion- contributing to Python 3 compatibility for modules you depend on! That will give you Python 3 experience :)
- 2008-2012 Python 3 becoming usable (byte formatting, six library)
- 2012-2016 Libraries (Django, etc) becoming compatible
- 2016-today Applications (Trac, Ansible, Chrome[1], etc) becoming compatible.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=942720
https://github.com/getsentry/sentry/issues/8806#issuecomment...
https://github.com/getsentry/sentry/issues/1152#issuecomment...
I mean, even supervisord is migrated at this point, and it was a long-time laggard.
Actually, I can't wait to remove it from my hard drive on Jan 1, since it's one of the most poorly designed apps I've ever used. It's really not surprising at all that they're not able to migrate it, assuming the quality of the app is indicative of the quality of the code. I wouldn't be surprised if the same was true of a lot of applications that are refusing to migrate. (I'll probably have to find an alternative to ebook-convert, the command line tool that's the only part of Calibre I use, or maybe I'll rewrite it in Python 3 myself.)
> No, it doesn't [need to convert to Python 3]. I am perfectly capable of maintaining python 2 myself. Far less work than migrating the entire calibre codebase.
That's a very strange quote. I want to have this much self-confidence.
The gui, Calibre proper, is a total nightmare. Functional, but my god is it esoteric and ugly. I've heard people actually use that gui as their primary ebook reading software and I just can't fathom how they find that tolerable.
https://manual.calibre-ebook.com/generated/en/ebook-convert....
https://imgur.com/a/nlAAlZn
Actually, depending on what action you pin dates to, it was twice as long.
One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.
I feel like this the python community has been the epitome of class regarding communication during a transition.
There are an increasing number of applications which require .Net 4.7, we found one early this year.
Promising "10 years of support" for a product is great, but if/when other vendors decide to undercut this, you can still be SoL :(
Mind that there is a feedback loop between data of current usage and an eol announcement.
If they announce an EOL close by this creates pressure to migrate.
You can still get Microsoft Windows XP support today. If you're prepared to pay enough.
I wonder how many of the people who're upset by this have ever or ever worked for companies that've ever sent anything more than pocket change to the people Python?
You could work on porting them or be part of that effort?
Hint for Hacker News commenters: 99% of the time, if your phrase includes the term "use case", you can safely just delete it and lose no meaning. It's just a way to say "for me" or "for them" that sounds more technical but really isn't.
In this case, you could say "This timeline worked out well for me".
* ducks and runs
"This particular individual" -> "this person"
I think the grandparent's usage of "use case" was totally fine. It wasn't distracting and it didn't change my reading of that comment in any way, shape, or form.
I disagree. HN is a place that seems to pride itself on the quality of its discussions, and on a higher intellectual caliber when compared to other Internet discussion venues. Surely a good command of language is part of that?
Beyond that, who are we to judge what constitutes "good command of language?" Which language are we even talking about here? I don't think HN is going to become a better place by becoming more elitist.
> I don't think HN is going to become a better place by becoming more elitist.
err...
EDIT: I think it's clear nothing more needs to be said. Feel free to respond to this comment or not. I've said my piece.
"For me" highlights the fact that my preferences, character, skills, etc., are different from other people's. Something might work well for me but badly for someone else because I happen to be good at working around its quirks, or bad at noticing its faults, or just not interested in the things it doesn't do.
"For my use case" highlights the fact that the things I need to do are different from other people's. Something might be good for my use case but bad for others' because I don't need very high performance but they do, or because I need the gostak to be able to distim the doshes backwards but they don't.
If I move on to doing different work and someone else takes my place, I expect something that works well "for me" to continue being useful for me but not for them, and something that works well "for my use case" to be useful for them but not for me.
"Use case" comes from 90s software engineering: https://en.wikipedia.org/wiki/Use_case
Corporate-speak and cliché idioms makes one sound less clever, not more. It might temporarily signal belonging to some crowd (for example, the HN tech crowd), but in the long term it hampers one's ability to communicate in an effective and elegant way.
I can think of countless annoying corporate buzzwords I see all the time on HN or at my job which are totally opaque and useless. "Use case" is two simple English words which anyone, including non-tech people, uses and clearly understands. This is not the hill to die on. I could link so many comments posted in the last week which are infinitely more buzzword-laden and irritating. If you really feel the dire necessity to chastise them, at least pick one of of those.
I do partly agree with you on "moving forward" or "going forward". I'm skeptical the situation was nearly as ambiguous as you suggest (it means "in the future", which is ambiguous, but it's no more ambiguous than saying "in the future", and anyone can easily request clarification if they hear "in the future"), but I had a few managers who said and wrote that like 30 times per day, and it does start to get on your nerves. Perhaps "use case" is similarly overused by some, but it also has a specific and clear meaning which would take longer to say/write than just using the term.
Notice that you are already in contradiction with the first criticism that I received in this thread, where a subtle difference in meaning was proposed.
> it means "in the future", which is ambiguous, but it's no more ambiguous than saying "in the future",
The main point is that it is totally unnecessary, we already have the future tense to talk about what will happen in the future.
The same applies here. Remove the phrase with "use case" and you get exactly the same meaning, with less words and less cringe.
"My use case" just generalizes "my {project, job, task, case}(s)". It's not ambiguous, because the intention is to be general. "For me" is a bit more general than that, though, and sometimes you want to be a little more specific.
The specificity hierarchy / subtle difference in meaning goes from "for me" (my attributes) -> "my use case" (my attributes + the case's attributes) -> "my [job/project/whatever]" -> "my [exact thing I'm specifically doing]". I think all can be valid, depending on the context. I maybe should've said "'case' or 'situation' for a particular project or task or goal done by a particular person (or group or organization)" instead (I was implying the latter part), but there's no contradiction here. By contrast, "moving forward" is typically implied and unnecessary no matter the context and can usually be cut as dead weight.
Source?
Where I am "use case" is definitely [still] tech jargon. I know very very few non-tech people who've ever heard it used, much less could give a definition for it.
But if if this is a hard-stop item for you at this juncture, then we should circle back... I'm sure we can align on this going forward. ;)
I think you feel that way because of the HN/tech echo chamber. Nobody says or feels the need to say "use case" outside of such circles.
> But if if this is a hard-stop item for you at this juncture, then we should circle back... I'm sure we can align on this going forward. ;)
Hehe ;)
Regardless, I would argue that "use case" has a quite specific and useful meaning that goes beyond mere corp-speak. I wouldn't use in conversation at a neighbourhood barbecue, but in a technical context (like a discussion of Python) the usage seems perfectly fine.
You seem to have reversed cause and effect here. New words/phrases/jargon comes into common usage when it is useful for communicating something. The difference might be subtle, but people wouldn't use the word if they didn't think that it was an important distinction to make.
In this case, you could have said nothing.
Where they only release security updates and no breaking changes?
There is also the case of Oracle, which defines support as "you can read our knowledge base and we will answer a phone before telling you it can't be done", meaning their support is literally for life (of the company). And they still manage to screw it up by deleting old KM articles...
Everything else in IT goes towards shorter and shorter support windows, because the field is always in flux and change (or rather churn) accelerates every year.
At the company I work at, we've got a large amount of Fortran code from the '70s that works fine with the latest and greatest Fortran compilers (barring deprecation warnings which help guide refactoring efforts). Same with C/C++ from the '80s.
Food for thought, anyway.
I've always thought Python 2 might be headed for the languages. Which is fine, it's great to have a programming equivalent of Latin.
Python is more like the English language... it's borrowed a bunch of stuff from many different languages and isn't even compatible with itself ;) (2 vs 3).
I mean, this is assuming with thing spoken languages are even at all similar to programming languages... which I don't think they are.
Hebrew was completely replaced with modern Hebrew and gets new changes constantly.
Python 2 sees new code all the time too. It's not dead! That's the whole point, it can simultaneously not see any new changes but still be used by those who value the absence of change.
Just to clarify further, modern Hebrew is mostly backwards compatible with biblical Hebrew, it's not an entirely new language. It was mostly updated in terms of vocabulary that was necessary for the modern era, plus some spelling/grammar changes.
Modern Hebrew speakers are able to read biblical Hebrew almost completely, though there are some differences (think of English speakers reading Shakespeare - though even less difference than that.)
There's a lot of money to be made doing migrations and keeping the beast itself alive.
I'm not complaining. I like Python 2.
The tone in this document is excessive and over-the-top. If the author spent half the document demonstrating (with examples) why Python3 is so great, it might actually be useful and get people upgrading like right now as they're reading it. But instead, it seems the author simply wanted to convey how sick they are of Python 2. The author does not appear to understand their users; that's their real frustration.
In life outside of Python... The transition in C/C++ from C++98 to C++11 and then C++20 (and beyond) has been quite clean and professional. There were some glaring issues with C++11 that later got patched up (e.g. rvalues but no optional, no filesystem, make_unique, etc). Most importantly, compiler support and standard distributions improved a lot. There were often clear incentives to upgrade, and it was relatively easy to stick to an old standard where necessary.
In contrast, Python has become a bit fractured, with a number of notable well-discussed but unaddressed loose ends in Python3: http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...
I think the Python community has failed to present strong enough incentives for upgrading to Python3, and that's why users are sticking to Python2 and 'slowing everybody down'. The jump to C++11 was obviously needed: at the very least, `auto` saved much of your sanity and you no longer really needed to include Boost in your build. But you could stick to an old standard if you wanted; you could even transition a codebase module-by-module in some cases.
The Python3 community seems to have been groping for a similar killer feature (e.g asyncio, as discussed in Amber Brown's talk above), but the value-add isn't so clear. `six` is honestly a nice catalogue showing how many changes in Python3 are largely sentimental.
Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
If people haven't found reason in the last ten years, then they aren't about to be convinced today. All the arguments for and against have already been widely discussed, and that the EOL of Python2 is here should come as a shock to exactly no one.
There's no reason to re-hash over and over what is already out there.
A bit? This is an incentive.
Me too. Anyone who's running 15+ year old free software which came with 6 or possibly 12 years of notice to upgrade to the new version (depending on how you count it) and is complaining that it's no longer going to be supported for free by someone else, is being quite amazingly arrogant...
Maybe it's unintended, users of free software are not always good at being gracious.
It's also arrogant to grab Python 2 out of the hands of people still using it and flush it down the toilet.
As choppaface said,
> Perhaps the killer feature missing from Python3 is a flexible, built-in Python2 runtime. Then maybe the transition would not have met such pushback.
If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided. I love Python and I love GvR, but he stumbled badly here IMO (not as badly as Perl 6, but that's small comfort) by trying, in effect, to cannibalize 2 for 3. I don't enjoy saying this.
I've met GvR briefly and he didn't seem arrogant at all to me. But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
That's a strange way to characterize "decide to no longer volunteer their own time." And by strange, I mean rude. If you want somebody to spend their time maintaining python2, why don't you cough up the cash?
> why don't you cough up the cash?
I am.
Second,
> "decide to no longer volunteer their own time."
If that's all they were saying I would STFU.
They are also telling everyone that, once they stop volunteering, Python 2 is dead. They insisted that the Tauthon project rename itself. It's one thing to say, "we won't support it", it's another thing to actively try to kill it, especially when they know people are still using it.
It wasn't. (And Tauthon is arguably a really cool name.)
But it does indicate that they want Python 2 dead.
> Van Rossum argued instead that if the Twisted team wants the ecosystem to evolve, they should stop supporting older Python versions and force users to upgrade. Brown acknowledged this point, but said half of Twisted users are still on Python 2 and it is difficult to abandon them.
http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...
Like I said, if people were just fading out of Python 2 that wouldn't make me call them arrogant, it's when they insist that other people have to ditch Python 2 that I start to feel like there's some arrogance there.
Like I said in a another comment, the only thing you get from switching to Python 3 is Python 3 compatibility. If Python 2 remains viable (which it will) there's much less incentive to use 3.
Python 2 isn't broken or bad or anything, it's just not Python 3. We aren't being urged to switch because 2 is (so much) worse than 3 but because it's a viable competitor to it.
Being less uncharitable, it indicates they want to avoid brand dilution (which is wholly reasonable.)
Look, I'm not really interested in proving that so-and-so is arrogant or not.
It's pretty clear to me that some people have some animosity to continued use of Python 2, and I find some of the language and attitudes smack of arrogance. I'm arrogant, and it takes one to know one, eh?
But I don't have a magic arrogance-o-meter so really what are we arguing about? Our feels?
Perhaps you could argue that the Python3 language could have changed it's name and "left" the trademark and reputation behind for some other random people to take over. But a stronger argument would be that the reputation Python has earned over the last two decades "belongs" to the ongoing team who built and supported it for way longer as version 2.X than they needed to and who've now been releasing it as V3 for over a decade.
If "people are still using" Python2, nobody is going to stop them. Nobody it deleting all the copies of the source code to Python2.7 or revoking any of the rights the granted when it was released:
"PSF hereby grants Licensee a nonexclusive, royalty-free, world-wide license to reproduce, analyze, test, perform and/or display publicly, prepare derivative works, distribute, and otherwise use Python alone or in any derivative version" (from: https://github.com/python/cpython/blob/2.7/LICENSE )
It you're uptight because the PSF owns and protects the trademark to the name "Python" where used in relation to a programming language _that they wrote and gave away and granted you extensive rights to do whatever you damn well please with their source code_ - that's a totally unreasonable expectation on your part.
Spend two decades building your own reputation for intelligent and responsive language design and stewardship, then walk away from all that reputation by allowing random people to piggyback off it, then get back to me and tell me how that's actually how shot should work... Guido and his team have put the hard yards in. They've given you pretty much free reign to do whatever you like with their source code. They are not only under no obligation to allow you to call what you do with that "Python", but they arguably have a responsibility to ensure that people who expect a historical level of stewardship and "benevolent dictatorship" of the language called "Python" are not mislead by people other than them using that name to continue to promote old and discarded technology and design decisions with any assumption that those new people deserve any of the historical reputation that "Python" implies.
Get over the "Wah! I can't use the name Python! I'm being oppressed!!!" childishness. I, for one, do not want _you_ specifically, and people like you in general, to fraudulently trade in the reputation that the Python trademark would bestow on your work if you were allowed to call it "Python".
Here: https://github.com/python/cpython/tree/2.7
Join the other 11.5k people who've forked it on Github, and an unknown number of people who've cloned it without playing Github's high-school popularity contest...
Nobody is ever going to take anything Python2 related away from you.
There's a lot of talk here about "arrogance", all from people upset that some other people have decided not to do any _more_ free volunteer work on a thing they've been trying to get people to upgrade from for 3/6/12 years depending on how you count it. Those people complaining about "arrogance" are putting words into the mouths of the people who've done so much free work for them over th=e last 20 years, accusing them of saying "fuck you" and of "grabbing things out of the hands of people" and of "cannibalising" the code they wrote 15-20 years ago while providing newer better code (which happens to not suit some people who're not prepared for whatever reason to update their own code).
GvR is _not_ the one seeming arrogant in this thread...
(And didn't the last line in my comment you replied to make it abundantly clear I knew exactly what arrogance the OP was incorrectly claiming, and what the actual arrogance on display was?)
No one is doing that. Python 2 is available, open-source software. The Python core team discontinuing development isn't grabbing it out of anyone's hands. Open source projects whose core teams have discontinued them in favor of an incompatible (either technologically or by licensing) alternative, or abandoned them altogether (or just not maintained them in a way that pleased the community), have often had maintenance picked up by alternative maintainers, who have often had to use alternative names for the independent continuation project. Nothing is taken out of anyone's hands by this.
> If Python 3 could run Python 2 code (even at just the granularity of modules) then all of this mess could have been avoided.
And we all saw how well starting with that goal worked for Perl 6.
> But I do find the attitude of "Hey, F. U." to those of us who want to keep using Python 2 to be pretty arrogant.
No one has that attitude (except maybe employers, but that's more about a desire to continue to get paid for using Python 2 than merely to continue to use it.) You are perfectly free to continue using Python 2 until the Earth is swallowed up by the Sun and no one will stop you, or even really care.
[1] https://www.businessinsider.com/oracle-customer-explains-aud...
There are tons of incentives to upgrade, but unfortunately very few to none can be considered killer features, and thus are harder to show off in a concise reminder about the sunset.
You have to give it a try and actually use Python 3 features to realize how much this improves your life as a developer.
Python 3 isn't perfect, but especially with later versions, it's a hell of an improvement over Python 2.
No, the quoted passage is exactly correct. Many major tools have dropped Python 2 support, and others have put that on their timeline. If you continue to stick with Python 2, you will lose out on the ability to use an increasing number of current tools, because the community is moving on. Relaying that fact isn't arrogant.
There was a discussion on HN about this a few years ago, but I am curious to see what does ninite.com plan to do now?
As an aside, a few weeks ago I interviewed at one of the top 5 investment banks for a software engineering role to maintain one of their main trading systems, written entirely in Python 2. My first question was what their plans were in porting what they called "one of the worlds largest Python 2 code bases," and it was "on the roadmap".
Surely the Python core team are aware that teams like this exist in some of the largest companies in the world, and I assume they've had at least some level of dialogue with companies like this to say "we're super serious this time, we're about to stop support for Python 2", or something along those lines?
Maybe it's a blessing in disguise that I was rejected?
If they start in the next few years, I imagine it'll be much harder to find ready and willing Python 2 developers with the experience to navigate such a big code-base? They could hire consultants, but I imagine the future hiring cost will also be astronomical.
But distribution vendors like Red Hat and Ubuntu have Python 2 in long term support distributions that they will give support for a few more years, so it is possible to use those. And after that they offer more years of support to paying customers. It's not necessary to hire programmers to do this for the companies needing support themselves.
That's because the Python community is too nice.
When Ruby or node broke compat, they just said "move or die". People moved.
When Python broke compat, they gave 7 years. People screamed, cried, complained, sweared it was impossible for them, that life was hard and the PSF was unfair.
They got an extension of 5 more years.
People still complained !
Hell, famous authors resented python 3 for years, refusing publicly to update their book.
On the other hand, the PSF had a very small budget, only few tiny donations and contributions by people or big companies that were saying they couldn't migrate that their lines of code. The same code that were making them a living, from a 25 years old amazing tech given to them for free.
My take on this is that if you are doing an open source project with a lot of volunteer work, don't be too nice. People have a tendency to abuse it. Save yourself trouble, and balance respect with users and convenience for you.
I don't think I disagree with your point in practice. Maybe in some details. I just don't think that not being credible in your plan to drop support on a given date is necessarily such a "nice" thing to do. You could say it's a "weak" thing to do. It doesn't help people prioritize the move and eventually hurts people by putting them into a jam on the day finally comes here. I think the ideal thing would be to break compatibility piece by piece, assuming it's really necessary, but be _understanding_ about it. Tell people "we understand that this is inconvenient for a certain number of people but have to cut it off at some place", not "stop complaining about free stuff".
Unless I'm missing something, this is a pretty disingenuous comparison. Ruby and Node breaking changes have been fairly small, Python 3 was anything but.
The platform can already run in python 3. It's possible that the team you interviewed with wasn't aware of that.
Like all big companies, personal experience varies with the team and the part of the company you're in.
I won't name names, but they're also in the top ten and based in America.
> Surely the Python core team are aware that teams like this exist in some of the largest companies in the world
Why would you assume they considered their users? Maybe they went purely for some abstract purity with tenuous benefits and didn't actually speak to their stakeholders. Remember, the "D" in BDFL stands for "dictator".
https://www.archlinux.org/news/python-is-now-python-3/
Edit: Yes Manjaro has default Python3 too. :)
Although their package management requires manually specifying the minimum accepted Python version for every single package, so they have thousands of packages that would run just fine on Python 3.7 but no one has the time to manually check and label them as such. So their default is still 3.6 and using 3.7 as your default version is not well supported.
I wish someone told me Gentoo is a non-starter before I wasted an afternoon installing it.
While we're on the topic, it's pretty stupid how PEP 394, the one that says "python should point to python2.7", gives its reasoning as "because all Linux distros except Arch do it this way" and then all the distros say "python should be python2 because the PEP says so" for the next 9 (maybe more) years. How is anything ever supposed to change?
Or use a Linux distribution like Arch that has python symlinked to python3 by default.
How many more decades must we wait??
If I have a modern C compiler, I can still run most C code from 30 years ago.
When I have a Rust 2030 compiler, I'll still be able to run Rust 2015.
But with only a Python 3 interpreter, I'm strictly unable to run the vast majority of Python code out there.
https://github.com/naftaliharris/tauthon/