They can't stop someone from releasing something that runs just like Python 2 and has a different name.
They can't stop someone from releasing something that runs just like Python 2 and has a different name.
As long time Python user, my view of the PSF is that they could mature a little bit. Their ambivalent hostility towards PyPy and Jython, the lack of portable standard library, and now with how they are continuing to mismanage the 2to3 transition. None of this is how adults should behave.
I wish PSF would pull the plug from python 2 much sooner so we wouldn't have to deal with whiners for 10 f...ing years. The problem with python 3 wasn't the incompatibility, the problem was keeping python 2 alive for so long. Other languages usually gave only 1 year and everyone moved, because they didn't want to stay behind.
Python 3 came out in December 2008. But for a lot of packages, it wasn't realistic to migrate until it was possible to support both Pythons from the same codebase. And that wasn't realistic until 2.7/3.3, which was 2012.
At that point the rising tide started and packages with no dependencies began doing dual support. But it was many years before there was enough coverage that application level packages like django could consider migrating.
So yes, the cutoff could have been somewhat sooner, but if the PSF had attempted to force a transition in 2009, it would have been a death knell for Python. Not even numpy was available for Python 3 until 2011!
https://www.python.org/dev/peps/pep-3000/#compatibility-and-...
Not hard to see why this didn't get a lot of traction.
Python barely survived 2to3, it should serve as a warning to every other system that thinks it can do a stop the world upgrade.
My C89 code, C++98 code and Fortran 77 code all still compile on a modern Ubuntu, and none of these are expected to break any time soon. The compilers just support multiple versions.
People aren't wrong to make different tradeoffs than you. Especially given that strict backwards compatibility is impossible (especially in a language like c/++, people will rely on things that aren't intentionally public, because they can introspect your bytes).
Compiler changes break code all the time, it's just almost always semantic and not syntactic. I find this amusing, since the syntactic changes are usually easier to detect and fix.
And python2 still works, it just won't get new features.
Probably more importantly, it wont get security fixes.
Yeah, Python 2 will still work. Ita not like there's a kill switch or anything. It just wont receive any official or supported updates. Effectively, Py2 will be abandonware.
I wish the wallrus operator was available as a future import, bit it's not.
Also, Python never had printf. It had a print statement; print became a function in Python 3. Yes, its a syntax change, but its for the better. Having print as a first class statement expands its utility and versatility.
You need very good test coverage.
Tcl 8.3 to 8.4 when they added unicode support as well.
I believe PHP did similar thing.
It was a major version release; Ruby, through 1.8, used an version numbering scheme similar to the old Linux version numbering scheme; odd second digits were development major versions, even second digits were stable major versions.
1.9 was a slight break because it was a major release but, IIRC, seen as stable.
You create a package called "constrictor2.7", and set it up to provide /usr/bin/python using update-alternatives. Then #!/usr/bin/python and #!/usr/bin/env python both work.
See eg https://lists.debian.org/debian-python/2018/05/msg00063.html from the Debian Python maintainer.
(That's a year and a half old, but I haven't seen a message go past suggesting they've changed their minds.)
If you already have infrastructure that does similar things, it's probably not much of an issue, but I can see missing or misdirected symlinks being a common problem. Maintaining the symlink in the distribution (Debian or whatever) reduces the chance of errors.
(Cynical? Moi?)