51–60 of 513 posts
No-GIL means better performance at the cost of being less beginner-friendly, right?
Earlier quoted context omitted.
people in this thread mention that, for some reason, "even with GIL you still have to write thread-safe code", which is an admirable stance, but I don't think many people do it, because their webserver or whatever uses the many single-threaded processes model and they don't want to waste time on that
Indeed. And the reason they use multiprocessing is bc they have learned that Python's multithreading is not a good option in cpu bound tasks. The blessing in disguise of course being that multiprocessing is also a shared nothing model, so (mostly) lock free programming is the default. Oth if you have a need for concurrently accessed shared memory/resources and need locks, it comes with an explicit cost. I think that'…
I hope it'll be recognised by the most "host" applications (uvicorn or whatever) that multi-threading is not a good idea anyway and they'll discourage it. But there'll definitely be a macho-land of thread-"safe" programmers whose bugs we'll be downstream of
Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.
A similar misunderstanding exists about SQLite and concurrency.. but that's a topic for another time.
never ever had a problem with GIL in python, always found a workaround just by spinning up ThreadPool or ProcessPool, and used async libraries when needed.
is there any use case of No-GIL which is not solved by multiprocessing ?
I thought Single threaded execution without overhead for concurrency primitives is the best way to high performance computing (as demonstrated by LMAX Disruptor)
Earlier quoted context omitted.
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.
Why would you even want a no-GIL Python? Java and C showed how much more effort it takes to maintain slower thread safe code for no real benefit. Parallelize at the fork level or at the isolated numeric library level.
Unpopular 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…
First, I don't see how the GIL would have much to do with free multithreading. The GIL should not have much observable logical impact on multithreaded _Python_ code. It should not make it more or less susceptible to race conditions. It's only practical impact should be slowness.
Second, your proposed "one GIL per thread" is pretty much the equivalent of the current state of multiprocessing. In that you fork your current interpreter state in an other thread with it's own GIL and start from there. This has been used for decades already, nothing new there. Sharing can be done through queues or shared memory.
As a Python developer, what would be the benefit of no GIL?
Unpopular 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…
> sane multithreading It's simply not "sane multithreading" not being able to run Python (byte)code concurrently. It's just a huge annoyance. > because it might lose its beginner friendlyness Python is not beginner friendly. It has one of the worst documentations out there. Also it does things very different compared to other languages (C#, PHP, Java, JS, ...) - I would advise anyone against learning Python as their…
Please read my post again. I am advocating a GIL per-thread model with an explicit feature for sharing selected objects. This allows for all cores concurrency, essentially like free threading yet with safeguards. I like to call that a sane way because it builds on decades of research and industry experience of the software engineering community.
> As to the PEP itself: It's optional, with the GIL being enabled by the default.
It's not optional if you build tools and libraries that need be able to run with both gil and no-gil.
What are advantages of non-GIL Python?
GIL is a promise from the internal implementation (eg CPython) of Python that things will happen atomically within the Python interpreter. This means that when multiple threads try to access and modify Python objects at the same time, the GIL ensures that only one thread can execute Python bytecode at any given moment, preventing potential conflicts and ensuring data integrity. However, this comes at the cost of limi…