Actually, there's been quite some speculation that PyPy could inherit the 2.x crown when CPython expires its support for 2.x (1 Jan 2020). PyPy is probably the best non-CPython Python 2.7 implementation, so it's a natural fit to some degree. I suppose it's all dependent on where the PyPy team wants to spend its time and whether or not someone might fund them for this effort (Canonical, RH, etc).
I don't know that they have the will to bug-for-bug reproduce CPython but the C API emulation layer added within the last few years probably means that it will be really high fidelity.
I don't know that I agree that it's a fiasco. I've been asked to work on a PDP11 in the last few years and while it was mind-boggling (the request -- I turned it down), it was understandable from a business perspective. So I can see how some businesses might want Just A Little While Longer on Python 2.x.
shrug, use python 3.x and don't sweat the fact that some folks are still stuck on 2.x. You certainly can't stop someone from offering support for 2.x -- the language is well defined and the reference implementation is open source. Anyone out there could put up a "Python 2.x Support: Cheap!" sign and be in business.
Reinventing the wheel keeps the circus going forever. As long as python 2 is supported I don't have to touch any of the scripts I have to "maintain". The moment I am forced to migrate everything to Python 4 (they broke everything already, why not again) I will have to deal with a huge amount of pointless busywork just trying to restore functionality.
Funnily I can still watch VHS movies on a relatively new TV. Just had to plug in the VHS recorder and play, meanwhile the description of 2to3 makes it look like a plug and pray.
I mean really? A script that might mention some cases it can't fix as warnings. "optional" fixes that replace missing classes with incompatible replacements, giving you the "choice" of fixing the mess by hand. Also an apparently unstable API for your own fixes, doubling down on breaking your code while you try to fix your broken code has to be dedication.
> Note The lib2to3 API should be considered unstable and may change drastically in the future.
Well, 2to3 works surprisingly well and I've converted tons of projects with it. Most major Python projects support both 2 and 3, so, private codebases, which "just work", should stay on the "just working" old versions of the interpreter instead of insisting maintainers to waste time entertaining their laziness, because things that "just work" don't require ANY updates, right?
If pypy wants to support 2, they can. If developers want to take advantage of that, they can. If library maintainers want to drop 2 support, they can. If others want to fork the libraries to provide security for the 2.x fork, they can.
What is not acceptable is trying to dictate what technology others choose to use to suit your personal preference.
Well, there's demand for McDonald's today as well, and people happy to supply to meet it! The Python community has dragged this circus for way too long it is now finally being put to an end. But there always will be dinosaurs who won't embrace progress and innovation, of course.
I could kiss this comment. You don't have a right to stop other people using py2 just so your ecosystem is a little cleaner. Yet that level of entitlement is apparently not uncommon in Python discussions.
There are two things in play here - one is that pypy is a large py2-only codebase that is unlikely to be ported. Second is that maintaining python 2 both does not cost much and it's used by the majority of our users, despite of what you hear on the internet. So, there is both good reason to keep it and a large amount of work to drop it.
I might be mistaken, but it was my impression that the changes to the 2.7 version now are mostly "core" changes that also apply to PyPy3. Basically, most language-specific work is going toward Python 3, and PyPy2 benefits when features they have in common are improved.
It'll be interesting to see if there's an upswing in PyPy usage over the next few months, for the explicit reason that they're not slated to drop 2.7 compatibility. I would imagine a noticeable percentage of 2.7 codebases without the available resources for a rewrite (that has by definition, no business value) would welcome anything close to a drop-in replacement. I'll be very interested to see if I'm wrong though!
I don't know that they have the will to bug-for-bug reproduce CPython but the C API emulation layer added within the last few years probably means that it will be really high fidelity.