It still blows my mind that the big "we're breaking backwards compatibility Python 3000" release didn't do anything to lay the groundwork for this, or any of Python's other structural problems.

▲

0xpgm 5 hours ago | parent | next [-]

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.

▲

seabrookmx an hour ago | parent | next [-]

That question is already answered. pypy only supports 3.11 today and is largely unmaintained.

▲

Pxtl 4 hours ago | parent | prev [-]

> 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.

▲

mohamedkoubaa 3 hours ago | parent [-]

This is slowly being addressed now, each version of Python sees the c API become more opaque.

	▲	jsmith45 22 minutes ago \| parent \| next [-]
		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.
	▲	twoodfin 35 minutes ago \| parent \| prev [-]
		Are there any PEPs that describe this work?

▲

jodrellblank 2 hours ago | parent | prev | next [-]

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.

▲

ModernMech 5 hours ago | parent | prev | next [-]

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.

▲

jeremyjh 6 hours ago | parent | prev [-]

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.