No-GIL means better performance at the cost of being less beginner-friendly, right?
Intent to approve PEP 703: making the GIL optional
21–30 of 513 posts
Re: Intent to approve PEP 703: making the GIL optional
#22Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though you…
> Personally I can see no good will come from bringing free threading to the masses
I’ve often thought that proper threading should be learned by the masses, not to be scared of it. This sort of statement does nothing but spread FUD.
Re: Intent to approve PEP 703: making the GIL optional
#23I’m glad they’re very conscious about how easily this could turn into a Python 4 debacle.
They’ll have to be intensely careful not to accidentally affect yes-GIL behaviour. All kinds of weird cases are possible if any sort of emulated GIL isn’t exactly like with a GIL.
Re: Intent to approve PEP 703: making the GIL optional
#24What are advantages of non-GIL Python?
Re: Intent to approve PEP 703: making the GIL optional
#25Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though you…
The GIL does very little to protect unexperienced users. It's still really easy to run into race conditions, for example, if your thread gets scheduled out in any multi-instruction operation (this is more common than you think [1]). In general, Python code still has to be thread-safe; you get the risks without the benefits.
If you don't care about CPU performance, instead of threads you should go for an event-loop approach (see asyncio in Python). As soon as you have threads (on a language-level, not implementation-level), there is some notion of implicit switching, and you run into issues. So, the language you're looking for is JavaScript, which is single-threaded and every context switch is explicit (in form of `await` or `yield`).
Re: Intent to approve PEP 703: making the GIL optional
#26With PEP703 you would compile Python either for multi or single-threading mode. The mode affects the ABI and therefore which C extensions are available. Eventually all C extensions would have an available port to the new ABI. The chosen solution is similar to how PHP used TSRMLS_ macros in the Zend engine - if threadsafety (ZTS) was #defined, all functions took an extra thread context parameter, breaking ABI.
How did it work out for PHP?
Honestly it didn't. PHP didn't get threads. It did eventually get Fibers though, which I suppose may have been in part influenced by this work
Re: Intent to approve PEP 703: making the GIL optional
#27No-GIL means better performance at the cost of being less beginner-friendly, right?
Not really. The GIL doesn’t actually make threading easier for a typical developer as they still have to worry about thread safety. You can ignore locks if you know what Python operations are atomic. But that’s incredibly perilous and you really shouldn’t try given that relies on implementation details. Eg. What if you didn’t realize a setter was overridden and setting to a dict-like isn’t atomic anymore?
It’ll make the Python source code much more complex and complicated, which is probably not a big deal, though I’ll say the CPython source is quite brilliant.
It’ll also mean for C library developers that they can’t assume Python opcodes are atomic. But I’m not sure C library developers will really mind too much because they already worry about this kind of stuff.
Re: Intent to approve PEP 703: making the GIL optional
#28No-GIL means better performance at the cost of being less beginner-friendly, right?
I think multi-threadedness is already an intermediate level concept so maybe its not a big downside. In turn, the ones that understand and need the performance get it.
Re: Intent to approve PEP 703: making the GIL optional
#29Unpopular opinion: This is a missed opportunity. What? Python could have been the one language with a sane multithreading model. Now it risks becoming a second version of Java. I fear this will make it a less attractive programming language, not least because it might lose its beginner friendlyness. For example, without the GIL a lot more care must be put into designing your programs. This can be true even though you…
Why convince you otherwise? You're the one with the weird opinion, you should be convincing us.
Heads-up, the parent edited their comment to remove that sentence and added some "convincing" instead, so that's why your comment looks out of place.
Re: Intent to approve PEP 703: making the GIL optional
#30there's a lot of code I wrote (and saw people write) in Python over the years, conscious that noone will ever run it in threads (ofc it's possible, but typically pointless), thus going quite easy on things that wouldn't be thread-safe. this used to quite a comfortable stance. community ended up inventing other ways to share state, other ways to vectorize, other ways to avoid blocking on I/O, that might sometimes be annoying, but evolved to be quite reasonable for Python.
giving up this stance? a lot of code is instantly a legacy, and a lot of it is a legacy people won't even know about before they notice the problems. and for what?
i must say that i have no experience running Python without GIL so my idea of the ways things can be not thread-safe is purely speculative/borrowed from very different languages (that I finally moved on to long ago, thank god). so maybe i'm wrong, i misunderstand the impact, and all this code is just fine