upvote
They weren't rebuilding the whole language.

https://peps.python.org/pep-3000/ - PEP 3000 says it will be a derived from the Python 2 codebase and not a complete rewrite (referencing Joel Spolsky's views on complete rewrites and Netscape Navigator).

https://peps.python.org/pep-3099/ - PEP 3099 is changes Guido van Rossum rejected from Python 3 (including := as a binding operator), parallel iteration, programmable syntax, parser going beyond LL(1), changing the for/else construct.

https://peps.python.org/pep-3100/ - PEP 3100 is things he set as goals for it, things like all strings are Unicode and byte arrays are a separate type, optional type annotations, 'exec' and 'print' change from statements to functions, None/True/False become keywords, old-style classes are gone, changing inequality comparison from <> to != , require C99, drop BeOS support, drop old standard library modules, and more.

actually, more changes than I remember.

reply
For a long time Guido wanted CPython to remain simple, as the reference implementation.

Probably also during the 2 to 3 migration, but that goal appears to have now been abandoned.

I wonder how the authors of other implementations like pypy will be able to keep up as the reference implementation becomes more and more complex.

reply
That question is already answered. pypy only supports 3.11 today and is largely unmaintained.
reply
https://pypy.org/posts/2026/10/pypy-v801-release.html

Last release on Oct 14. Beta support for 3.12. It's not that bad really and 1/10 of the people who complain about it did something then the situation would be better.

reply
> the reference implementation.

The problem was he exposed too much of the implementation into the language itself, destroying its ability to be a simple reference implementation that others could re-implement.

reply
This is slowly being addressed now, each version of Python sees the c API become more opaque.
reply
That's at best a partial fix for the API side. Python side CPython sill exposes a LOT of implementation details, and as a result occasionally projects will choose to rely on some of these details. Then other implementations need to decide whether to also pick the same implementations details and expose them, or use different details, and lack compatibility with any library that depended upon them.

The python documentation has historically also not been especially clear at distinguishing between what the language guarantees, vs what is just implementation details of the cPython implementation. So even if libraries wanted to try to avoid depending on implementation specifics, it isn't always clear what those are.

The net result is that for the end user python the language is effectively: whatever cpython does. This really, really discourages creating alternate implementations, as the only way to be an alternative implementation with good compatibility is to be a living fork of cpython, constantly merging in all the changes from it, while also maintaining your improvements.

reply
This is also slowly being addressed
reply
Are there any PEPs that describe this work?
reply
They reference this one in the article https://peps.python.org/pep-0836/
reply
I meant the trend of making the C interop more opaque.
reply
See the stable ABI for Python 3.15 and PEP 793, 803, 820 for recent movements in this general direction and the following draft: https://github.com/py-ni/peps/blob/main/peps/pep-08xx.rst (the py-ni project is pushing for this)
reply
At the time, Python had a clear purpose as an easy to learn "glue" language between other, perhaps more performant languages. There was no reason to make Python as fast because that would muddy its purpose by introducing compromises and complexity. For better or worse Python sat pretty well in its niche.

Today there are far more people using it, and everyone has a different perspective on what it is. No longer is it a niche glue language, now it's a backbone of AI technology at major tech firms, so it's understandable they'd like it to be faster on its own.

reply
Its possible this could have been the concrete pillar that broke the camel's back and set Python 3 on the path of Perl 6.
reply