RustPython: A Python Interpreter Written in Rust

does it have a GIL

idk but Jython didn't. So I don't think there's anything inherent in the language outside of CPython that calls for it.

Iirc, it mostly impact C modules in terms of the guarantees that are offered / not offered with GIL / NOGIL.

Yeah, but the ecosystem of C modules is what makes Python so great.

The complete semantics of Python object lifetime are expensive to implement in a compatible manner without a GIL. Jython got around this by not doing it, making it not fully compatible (yes, people do depend on objects being eagerly freed), just using the JVM GC instead. If you do want full compatibility, the choice is between single-threaded performance and parallelism.

> yes, people do depend on objects being eagerly freed

I get that this must be one aspect of the necessity of the GIL but I mean, C++ also has eager free behavior due to RAII and threads are working fine there, as long as you know what you're doing. Perhaps that's the rub though, it's pretty easy to crash/deadlock in C++ and we blame the programmer rather than the language.

It's what makes Python tolerable.

There is a competing c interface that numpy and a few other projects are adopting that allows for no gil. Last time this came up I thought the rust implementation used that one.

Hadn't thought about Jython for a while. Whatever happened to that?

One of the casualties of the Python 2 => Python 3 debacle, it seems.

Idiomatic C++ relies much more heavily on ownership and not so much on refcounting. If you have code that's a rat's nest of shared_ptr, it's going to perform very poorly in a multithreaded environment. But that's why any C++ guru will tell you to not make a rat's nest of shared_ptr. When refcounting is commonly used in C++, like with GUI code or dependency graphs of network requests, it's usually in non-performance-critical sections.

In Python, by contrast, all variables default to object references, and so nearly everything you do involves updating a refcount.

It's special-purpose, and always has been. You use Jython when you want to embed a Python-like interpreter into a Java program. Usually when you do so, you're scripting the objects of the Java program, and don't need or want to import arbitrary Python packages. Indeed, that's often the whole point of Jython - the system designer wants a language that's familiar to Python programmers, while also being able to control the environment that those Python scripts can access.

This is not different from the Python 2 days. Jython has always had subtly different semantics from Python (eg. it uses Java strings instead of Python ones, there's no C API, it relies on the Java GC so no eager free), so many common libraries wouldn't work with it. Just try to run NumPy on Jython - you can't, despite the same developer authoring both Jython and NumPy's predecessor.

Right so you're saying that Python's need to keep ref counts is what leads to the need for synchronizing updates, leading to the need for a lock, more or less. Which is only needed in C++ if you program in a kind of Python style. Makes sense and is a good point.