As others have said, maybe this project fixes some actual problems and backports some features from 3, but this isn't "Python". Beyond the fact that Python is a trademark of the Python Software Foundation, Python is more than the language, it's the community and the tools (as with every programming language). So while there are some vocal people that really dislike Python 3 (either in part or wholly), my understanding is that with the planned phase out of Python 2 and Python 2 only receiving bug fixes at this point, much of the industry is transitioning to Python 3 (either currently doing so or planning to) and so it seems relatively fruitless to attempt to build upon Python 2. I personally think the effort put into this would be much better spent making tooling around Python 2 to 3 transformations.
I also think it's pretty irresponsible of the author to call this Python 2.8, because it may cause confusion to developers unfamiliar with the history and come from a tutorial that is still in Python 2 (it does show up on the first page of Google for me). It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it, and 2) it can cause significant confusion when code doesn't work when it hits an edge case, and then the whole tooling around it can't be guaranteed to work. The last thing I'd want in my programming language is unaccounted for ambiguity.
> It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it
It is possible actually, that's kind of the point! The interpreter I've been working on passes the 2.7 unit tests (i.e. those in Lib/test/), and as well as unit tests for the new features that have been backported from Python 3.
Even if you don't believe me, it's interesting to note that, e.g., while Python 3.0 was being developed, function annotations and keyword-only arguments coexisted with tuple unpacking. I built the code and ran it myself, in fact: https://twitter.com/naftaliharris/status/784421498291310592. Tuple unpacking was actually removed later, introducing the backwards incompatibility after the new functionality had been added. Timeline:
Oct 2006, keyword-only arguments.
Dec 2006, function annotations.
Mar 2007, removing tuple unpacking.
There was also a promising backport of keyword only arguments to CPython 2.6 (!) that was never merged, (http://bugs.python.org/issue1745), due to lack of follow-through.
I don't know about that. It forked a Python compiler, and is fully interoperable with 100% of Python 2 code, and much of Python 3 code. It's even compatible with Python C extensions.
Why isn't it a valid Python compiler?
To me, the whole morass about trying to end-of-life Python 2 is a bit silly. People have gotten emotional about the situation.
On one side, people like Zed Shaw are calling the Python maintainers 'evil' and claiming conspiracy.
On the other side, people are calling companies using Python 2, 'lazy' and claim they're a threat to the ecosystem.
Yet elsewhere, C is still being written in all of its various year-specific formats, and people end up using 'old' versions simply because they join pre-existing projects or need to totally interface with something that's written in an 'old' version.
Python is an extablished language, it's likely that 10 years from now there will still be Python 2 codebases going strong.
That's the thing - people expect core developers (some of them working on the project for free) to keep backporting crap out of the kindness of their heart. It's like asking Microsoft to backport security fixes and .Net features into VB6.
There are some fair points, but unlike C or other languages that have "old" versions, most of the newer versions are compatible with this old code (as in, if you have some C89 code, you can compile it in the newest C compiler. Same with Fortran). This isn't the case with Python 3 (there are breaking changes), and I think it's fair that the Python core developers who, besides Guido, probably work on this for free decide that it's time to end the older, non-compatible version and give ample time for developers to move their codebases, adding bug fixes and security fixes in the mean time until EOL is reached.
My biggest gripe with this project besides calling this Python is that it's seemingly ambiguous with its code compatibility. I don't mind ambiguity in programming languages, but generally the ambiguous cases are explicitly defined with cases to explain them, and I don't see anything of that nature here, only something that vaguely says that if there's something that works in both the Python 2.7 way will be the default. Without defining those it's hard to know what could happen in an edge case and this could introduce specific bugs that don't present themselves immediately but introduce data weirdness because the cases where something may be ambiguous wasn't defined.
In any case, I think that if a company has a really big, maintained code base in Python 2, it's their fault for supporting an older, in-2020-unsupported version of a programming language and the money/developer time spent supporting the codebase could be spent transitioning it to Python 3. I can understand a little more with an open source project because time is more precious and generally that time is donated, but even then most bigger projects (Numpy, Scipy, Django) have moved to Python 2/3 compatibility so unless the project is gargantuan there's no real excuse besides the project is not maintained.
They transitioned with a lot of community support and did sooner the course of years. It wasn't easy to support 2/3 out of the box. For a normal company, staying on 2 is like keeping technical debt and we all know how companies loathe to allow weeks for major refactoring when the gains aren't immediately visible. My company switched to using puppy and eschewing c extensions before we supported python 3.
As I said, it's my understanding working with Python as well as seeing what others work with in the community and so it could be wrong. Do you have data to back up that people aren't?
I also think it's pretty irresponsible of the author to call this Python 2.8, because it may cause confusion to developers unfamiliar with the history and come from a tutorial that is still in Python 2 (it does show up on the first page of Google for me). It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it, and 2) it can cause significant confusion when code doesn't work when it hits an edge case, and then the whole tooling around it can't be guaranteed to work. The last thing I'd want in my programming language is unaccounted for ambiguity.