I'm glad Guido considers this a toy. Anyone interested in helping out the github repo is here:
I could see security fix releases be useful. Giving people more time to transition is going to benefit some projects. But in terms of feature, it does sound toyish.
Appart from that, it actually doesn't look like there's any problem here. The maintener agreed to change the name.
I don't expect this project to exist for very long unless it breaks free, but if it tries to just bring 3 features back to 2, I'm not sure it'll make sense for very long.
> Backporting features will be hard
It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for example, here's my recent implementation of the "nonlocal" keyword; you can see the commit messages reference the Python 3 commits: https://github.com/naftaliharris/placeholder/pull/60
> Why try to create an inferior python 3?
The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. Unfortunately, there is some code that runs and has different behavior under Python 2 and Python 3 (e.g., 'print("a", "b")' ), so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there. I decided to defer to Python 2 behavior in those cases, since most of my code is in Python 2 and I don't want to change it. :-)
That is a great goal, I fully support you.
so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there
Even if the interpreter has to decide, "this file is python2, it will do it one way.....that file is python3, it will do it another way" that is good enough. As long as you can call functions and such between the two files.
Because you're importing big legacy python2 libraries.
Python 3 was released in December 2008. Python 2.7 was released in July 2010, and was given 5 years of support which was then extended to 10.
Those people who have not transitioned yet have not done so because of lack of time. They might have valid reasons for delaying, but time is not one.
In 2020? There will certainly be a business case once you get hit with an RCE in 2.7 because there will be no new security patches.
I think the point is -- it will not be an inferior python 3.
It will be a python 2 with the best non-code-breaking parts of python 3. Sane byte handling + bug fixes - breaking changes.
That will make it a superior python 3.
For the vast majority of the actual planet, this simply isn't the case.
Depends what you're working with, obviously.
PS. https://python3wos.appspot.com/ now shows only few packages not marked as compatible from the most popular ones. One group (carbon, graphite, supervisor) are not libraries so they don't really affect others. The other is specific moz* libraries - and they're for Mozilla's internal testing, so nobody else should care that much.
- you need to choose either bytes or str, you can't have both. And Python 2 API have many functions accepting and returning bytes while Python 3 have many ones with unicode.
- the C ABI and the byte code changed.
- built-in changed.
So you will have to choose between one behavior or the other and deal with it. This is what you do with the excellent six or Python-future libs. They let you write 2/3 compatible code, but the first thing they do is making you choose either the 2 or the 3 behavior.