[zarzavat]

How is that Python’s problem though? If you paint yourself into a corner by choosing the wrong language then eat the rewrite or eat the hardware costs.

There was a consensus after the Python 3 debacle of “No major breaking changes”. We seem to have lost that because of moneyed interests and that’s sad.

[emblaegh]

That's such a strangely distorted world view. If a car company releases a, idk, trunk-extension in response to customer feedback would you go "How is this Ford's problem? If you didn't think about the trunk size eat the loss and buy a new car" ? Python developers want python to remain useful to the developers who want to keep using the language. It's not an incomprehensible motivation.

[zarzavat]

If I attach something to my car it doesn’t affect your car.

Who does no-GIL benefit? For the majority who use Python for single threaded code, no-GIL will make their code slower because a thread-safe interpreter is always going to be slower than one that can assume ST operation.

For the minority who want parallelism, there’s two other options: OS processes and subinterpreters. If you can use either of these then you will get better performance with a GIL for the same reason.

So no-GIL will only be faster for a minority of a minority who want parallelism but can’t use OS processes or subinterpreters.

Meanwhile everybody else writing libraries has to make sure that their code is no-GIL safe, to support this tiny minority, and if no-GIL ever becomes default then everybody else has to do something to turn it off.

It’s such a stupid idea.

[emblaegh]

> If I attach something to my car it doesn’t affect your car.

Yes, that was my point.

> For the majority who use Python for single threaded code, no-GIL will make their code slower because a thread-safe interpreter is always going to be slower than one that can assume ST operation.

I'm almost sure the python developers said that they will compensate the slow down with other optimizations, so that you'd never have single-threaded performance degradation version-to-version.

> So no-GIL will only be faster for a minority of a minority who want parallelism but can’t use OS processes or subinterpreters.

One would hope to 1. open new use cases for python thus attracting developers that would have otherwise not given the language consideration and 2. other users could benefit from new optimizations that could be implemented further down the dependency stack.

Of course there's no guarantee that that will materialize, but the idea the adding support to an established, lightweight and well-supported concurrency primitive is so obviously a "stupid idea" shows to me that your (rudely expressed) opinion is entirely self-centered and nearsighted.

I might add that the move from python 2 to 3 was incredibly painful, but I assume most agree (with the benefit of hindsight) that it was entirely correct.

[BerislavLopac]

> I'm almost sure the python developers said that they will compensate the slow down with other optimizations

Those optimisations are not there to compensate anything; they will improve performance of single-threaded code with or without GIL.

[emblaegh]

That I meant to express yes. That those non-GIL-related optimizations would soften the blow of any slowdown from the GIL removal project.

[BerislavLopac]

Maybe, but making GIL optional (rather than removing it completely) solves both problems.