What a year!
Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!
Python 2.x dying; Python 3 becoming the norm; "Perl6" renamed to raku & Perl5 thinking of bumping to v7... and now Ruby going all the way to v3.0!
Towards Crystal 1.0:
https://crystal-lang.org/2020/03/03/towards-crystal-1.0.html
Here is a walkthrough:
(Or Java getting new maintainers...)
:-D
So from the perspective of an application developer who uses package dependencies, using Python 2 was the norm until 2015 at the earliest? That sounds about right to me.
Even conservative CentOS (where Python is a base dependency for the system, as opposed to the above) is on Python3 as of now though.
As far as I am aware, Debian 10 buster is the last mainstream LTS distro to default to python2. Should change next year with Debian 11.
Or not... it's not like you can't throw a python 3 dev at an old python 2 codebase and tell them to work on it. Even if that probably wouldn't make them very happy about it, they wouldn't be lost.
But I'd bet an arm that there will still be python 2 codebases running in production in the next decades with companies very unwilling to do the work of migrating it.
But honestly, there are more breaking changes between two versions of ruby than between python 2 and 3. And during the time python 2 was still supported (until the last day of 2019), most features that made it into python 3 and could be backported were backported into python 2.
It will be a pain for those who aren't used to python 2 encoding errors and other nice stuff that they got rid of in 3 to make it a nicer and more robust language. And the will miss the new and shiny features that will make it in new python 3 version after python 2 EOL.
But apart from that, it's almost the same language, they just made the transition from 2 to 3 to be able to introduce some breaking changes in places that unfortunate design choices had made their way into the language and couldn't be rolled back because people running python 2 in production depended on those. So they upped the major version, introduced some breaking changes (but not that much really) and gave developers 10 years of support for the older language so they could port their codebase to the new version.
And porting a python 2 app to a python 3 app isn't such a hard task. But! If you've got a big app that's working now, even if the changes aren't that drastic, you can't be sure that the port won't introduce some hard to find bugs that will be a pain to debug. Hence why plenty of companies are still running python 2 versions of their apps and will do so for the forseeable future.
But, throwing a python 3 dev at a python 2 codebase is totally doable, it's just that the guy or gal will miss the shiny stuff that didn't get backported into 2 and will break their teeth on some behavioral changes between the two languages.
I can't help but contrast this with the upgrade from Ruby 1.8 to 1.9. It was also painful, but no one in the community was holding on to 1.8 years later.
I mean it has only been 11 years since Python 3.1/2.7 and that's probably a common lifespan for maintenance mode code projects? 3.5 is still supported and that one is 5 years old. Why the hurry.
Because some people will always leave it to the last moment or beyond. Meanwhile the Python team has had the overhead of supporting more code than necessary.
One difference is that upgrading Ruby from 1.8 to 1.9 brought a significant performance increase, whereas going from Python 2.x to early 3.x, performance actually got worse.
AFAICT this was mostly caused by the removal of the machine-word-sized integer type - in Python 3, even 1+1 is calculated using arbitrary-precision integers.
Python 2 => 3 had lots of other problems as well - ultimately they changed just enough to break everyone’s code, but not enough to make upgrading worthwhile.
https://devblogs.microsoft.com/powershell/announcing-PowerSh...
I don't know that it's certain it ever will be default on Windows, IIRC the last things I read were that it might become an optional package in Windows.
[1] Six-monthly, now moving to annually to align with new versions of .Net Core.
Almost entirely backwards compatible with huge performance gains.