As much as I wanted to like this article (I remain optimistic about the future of Python as Python 3) wouldn't most of the compelling additional features suggested break backwards compatibility with current versions of Python 3? This strikes me more as a proposal for a Python 4 than a revitalization of Python 3.
edit: I wanted to respond to this myself, since upon rereading I no longer get the impression the proposed changes need 'break' backwards compatibility per se. For the suggestion on removing the GIL specifically, this would completely necessitate a revolution in the design of python programs such that even if, say, the libraries that had already been ported at the time of 3.2 still work in 3.9, their implementation would be senseless by 3.9 conventions.
With stuff like this, any ports of existing Python 2 codebases are wont to lead to tons of subtle bugs. No wonder Python 3 adoption is as low as it is.
What would be the point of this? Are you suggesting PyPy forks the Python language itself? PyPy hasn't implemented new core language features, and I don't see them doing so in the future. Python 3 is actively developed, fixing many warts in the language and adding great new features.
As annoying as the transition to Python 3 is, it's the future of the language. I was actually one of the curmudgeons who stuck with 2.7 and grumbled about not wanting to switch until a few months ago. I've accepted that I need to, at the very least, start new projects in Python 3 wherever possible. The vast majority of popular third party libraries have been ported over at this point. Python 2's death is inevitable, even if it will take many more years.
This recommendation should really be updated IMO. `python3` will never see full adoption as long as `python` is reserved for Python 2. I understand the need as a compatibility thing, but at some point the forward-looking cost of distinguishing `python3` exceeds the legacy cost of applications that just say `python` when they mean `python2`.
No, I'm saying that the problem you worry about doesn't exist.
The problem -- as you point out -- with 2 -> 3 was that supporting both versions was very difficult. Because Python 2 couldn't run Python 3 code (and vice versa).
And thus libraries existed in awkward states for years.
But GIL can run no-GIL code. Supporting both is no harder than supporting one of those options (the no-GIL one).
The article misses a key point: people aren't going to migrate to Python 3 unless and until the most common libraries have been ported over.
About a year ago I tried to mass-upgrade my many Python apps to 3, only to discover that about half of them required one or another library that was unavailable in 3 (and remain unavailable).
To me, the syntax and other changes are a small issue compared to the fact that many of my apps would simply stop working, and with no recourse.
Breaking backwards compatibility is dangerous in any major project. Hopefully the community will migrate reasonably fast and this don't turn up the same as Python 3.
But imagine what would happen if they had created a compatibility layer. Yes, it would be very hacky, and require a lot of seemingly gratuitous work - tons of standard library functions would have to check the compatibility version of the caller and change behavior accordingly. And the goal of cleaning up the codebase by removing things like old-style classes wouldn't be achievable. But what if that work had been done, and the mess accepted?
Then Python 3 code could use every unmodified Python 2 library (albeit potentially requiring the former to do some messy conversions between str and bytes when making calls), including the long tail of legacy libraries that will never be upgraded. Meanwhile, once the issues in the first Python 3 release or two were straightened out, there would be very little reason to use the Python 2 interpreter, since the Python 3 one would be a drop-in replacement; so migration to the latter would be relatively swift, and it wouldn't be too much of a burden to ask someone to upgrade as a prerequisite to using your code. So there would be very little reason to write new Python code in the Python 2 dialect (unless you really really hate making print a function :), and existing code could be migrated one file at a time. Including popular libraries that wanted to maintain backwards compatibility with Python 2 programs - they would have to add compatibility checks similar to the standard library, but could otherwise go full Python 3, rather than having to use the awkward intersection of language semantics and compatibility libraries currently required.
With the transition so much smoother overall, native Python 3 code would probably take over relatively quickly. (Maybe it would have even been feasible to remove the Python 2 compatibility layer eventually, though probably not.) Whereas in reality, today, over 7 years later, Python 2 is still more popular than Python 3 [1].
If the Python core developers care so much about practical usage they should never have released python3 with features that break backwards compatibility.
Your argument is right, but they should have thought about that before fracturing the python community.
That's the exact attitude that lead to decades of pain with the 2 to 3 transition and libraries though. There was zero plan for how to help libraries migrate from python 2 to 3, or more importantly how does one library support _both_ python 2 and 3 from one codebase as their users take time to switch their python interpretor. The attitude of "just turn off GIL if you don't need it, just use libraries that support turning it off" means library authors will be asked to provide versions of their library that do and don't support non-GIL mode. That's a big burden to dump on library maintainers.
I feel like it's still a better idea to migrate back to python 2.7 and update it to match python 3 features in a backwards compatible way. At the very least there needs to be a way to interop between python 2 and python 3 code without modifying the python 2 code.
I haven't used python for a while though. Maybe they found a solution to the python 2/3 problem already.
This seems unfair to Python 3. The Python community, including the developers of Python 3, have not been encouraging people to migrate to Python 3. In fact, it was never in their roadmap for people to migrate immediately. The common wisdom has always been 'When starting a new project from scratch, if all the libraries you need are ported, and you won't need backwards compatibility down the road, then use Python 3. Otherwise, use Python 2.x'.
It's quite difficult to get people to use your new version when you actively tell them that it's probably not a good idea right now.
I am also annoyed by Python 2 vs Python 3 situation, however not because of the current incompatibility but about the potential Python 3 vs Python 4 incompatibility that the Python developers have shown to not care about introducing in the future.
If they promise to never break backward compatibility again in the future i might change my stance though, i mostly try to avoid Python than anything than a simple calculator or quick and dirty scripts because i do not want to write any code that may break in 2-3 years without me doing anything wrong.
On the other hand breaking compatibility the way they did with Python 3 is reckless. Ask someone who has a huge code base with, say, test scripts that do 'print' a lot if they are eager to switch to Python 3.
The push for Python 3 has been happening for over 10 years at this point. At what point do you expect people to be able to stop supporting a very outdated distribution of any software?
6 years ago my company switched to Python 3.5 and there was a big push in the community at that point to move away from Python 2. I mean Python 3 came out around the same time as Windows Vista, which has been unsupported since 2017.
edit: I wanted to respond to this myself, since upon rereading I no longer get the impression the proposed changes need 'break' backwards compatibility per se. For the suggestion on removing the GIL specifically, this would completely necessitate a revolution in the design of python programs such that even if, say, the libraries that had already been ported at the time of 3.2 still work in 3.9, their implementation would be senseless by 3.9 conventions.
reply