What's in a name?

Posted Dec 6, 2025 14:05 UTC (Sat) by rrolls (subscriber, #151126)
Parent article: Eventual Rust in CPython

I wasn't aware there was already a RustPython until I read mirabilos's comment above, but I'm not surprised it exists.

So my stance is very much: leave CPython alone, please and thank you.

Yes we all love to hate C, but it has its place. Mostly that place is not fixing old code that ain't broken. I've attempted to compile a few language implementations from source over the years, and I have to say that CPython was one of the easiest, largely thanks to it being plain C.

If the PSF wants to endorse a Python interpreter written in Rust, it should go the whole hog: focus development and resources on completing the implementation of RustPython, officially endorse it as "the default Python", and label CPython as the alternative.

Bringing Rust into CPython would only create a mix of legacy and new-fangled, which is surely the worst of both worlds. It gives you all the annoying requirements of the new thing, and doesn't remove any of the burdens of the old thing you wanted to get rid of.

At the very least, don't call CPython CPython if it's not going to be C anymore.

Personally, I'd like to see a ZigPython.

to post comments

What's in a name?

Posted Dec 6, 2025 15:59 UTC (Sat) by ssokolow (guest, #94568) [Link] (1 responses)

So my stance is very much: leave CPython alone, please and thank you.

Given that the people who opened the discussion were "two of Python's core developers", and you're not paying them, one could argue that the "fair and kind" way to "leave CPython alone" would be to just abandon it and mass-exodus to some kind of "NeoPython" fork, like how LibreOffice came to be when Oracle bought OpenOffice.org, leaving people like you free to take up maintainership of CPython.

It's their project and they're free to do whatever they feel is best... especially if they're not getting paid to do it. You're free to fork the last version you like. That's the FLOSS social contract.

(It's not as if Microsoft was obligated to continue supporting Windows 98 SE or Windows XP or Windows 7, and it's not as if the Linux kernel would have been obligated to keep Firewire support if not for someone stepping up to maintain it.)

What's in a name?

Posted Dec 6, 2025 19:03 UTC (Sat) by josh (subscriber, #17465) [Link]

Exactly: the project is not obligated to keep "the last C-only version" alive, but you can make such a fork yourself if you believe that people would rather use your fork than the official version of Python.

What's in a name?

Posted Dec 6, 2025 16:50 UTC (Sat) by ptime (subscriber, #168171) [Link] (2 responses)

The Zig compiler and manuals are freely available as soon as you’re ready to get to work.

What's in a name?

Posted Dec 7, 2025 1:23 UTC (Sun) by atai (subscriber, #10977) [Link] (1 responses)

Why is anyone ready to do this work？Or wants to do this work?

What's in a name?

Posted Dec 7, 2025 10:09 UTC (Sun) by intelfx (subscriber, #130118) [Link]

>>> Personally, I'd like to see a ZigPython.
>> The Zig compiler and manuals are freely available as soon as you’re ready to get to work.
> Why is anyone ready to do this work？Or wants to do this work?

How do I care?

This is the single possible response one can get in FOSS when one says "I want to see X" (or, conversely, "I don't want to see X that someone else is doing"): get to work yourself.

What's in a name?

Posted Dec 7, 2025 5:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> If the PSF wants to endorse a Python interpreter written in Rust, it should go the whole hog: focus development and resources on completing the implementation of RustPython, officially endorse it as "the default Python", and label CPython as the alternative.

Yeah, like they did with Python 3.

Rewriting something from scratch while the original product is still being used is almost always a bad idea.

What's in a name?

Posted Dec 7, 2025 18:23 UTC (Sun) by alx.manpages (subscriber, #145117) [Link] (2 responses)

> Yeah, like they did with Python 3.

The problem with Python 3 was backwards compatibility of the language.

> Rewriting something from scratch while the original product is still being used is almost always a bad idea.

In this case, the problem is simpler:

Rewriting something from scratch is almost always a bad idea.

Some caveat is true:

Doing it while you use it makes it less terrible, because you'll get bug reports gradually, so you boil the frog alive. If one offered the rewritten version at once, the amount of bugs would be so high that no-one would accept it.

But it's still a bad idea.

What's in a name?

Posted Dec 7, 2025 18:55 UTC (Sun) by khim (subscriber, #9252) [Link]

> Rewriting something from scratch is almost always a bad idea.

Not true. I've seen things being rewritten from scratch by someone to become much better. In Linux and outside of Linux.

But the catch there is one: if something can be understood and written by one, single person (or, maybe, very small group of persons, 3-5 people with one lead and a few helpers) then things work beautifully, very often.

If something couldn't be understood and written by one person in a reasonable timeframe (couple of years tops) then rewrite, very often, just becomes a mirror of the first attempt, just with glaring flaws in a slightly different places.

What's in a name?

Posted Dec 7, 2025 22:59 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

> Doing it while you use it makes it less terrible, because you'll get bug reports gradually, so you boil the frog alive. If one offered the rewritten version at once, the amount of bugs would be so high that no-one would accept it.

It's more than that. For complicated products, it's almost always impossible to replicate all the behaviors without actively keeping two codebases in sync. In both directions. And this is doubly complicated if the original branch continues to get new features. Perl 5 vs. Perl 6 comes to mind as a good example.

What's in a name?

Posted Dec 8, 2025 9:44 UTC (Mon) by danielthompson (subscriber, #97243) [Link]

> If the PSF wants to endorse a Python interpreter written in Rust, it should go
> the whole hog: focus development and resources on completing the
> implementation of RustPython, officially endorse it as "the default Python",
> and label CPython as the alternative.

I think this misses the difference between having a Python interpreter written in Rust and having a Python interpreter written in <who-cares> that provides official Rust and C APIs for extensions.

Part of Python's culture, and value to new programmers, is the "batteries included" standard library. If a large number of extensions start to be written in Rust it might well be detrimental to the ecosystem to have to say "that would be a great addition to the standard library but you need to rewrite it in C".

I'd say that's the most valuable part of the pre-PEP: seeking to provide road map and advice on people writing new Python libraries that might be good candidated for the standard library.