[Tuna-Fish]

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.

[radarsat1]

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

[nostrademons]

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.

[radarsat1]

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.