Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intent to approve PEP 703: making the GIL optional

discuss.python.org

Post reply on HN
Print view View original

31–40 of 513 posts

Re: Intent to approve PEP 703: making the GIL optional

#31

Post by paulddraper »

miraculixx wrote: post #16

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…

Python is already Java but worse.

All of the multithreading bugs without any of the multithreading performance.

Re: Intent to approve PEP 703: making the GIL optional

#32

Post by KMnO4 »

vasili111 wrote: post #24

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 limiting the full utilization of multiple CPU cores for certain CPU-bound tasks.

Non-GIL adds some complexity to the implementation and some risk when writing multithreaded code at the benefit of improving performance.

Re: Intent to approve PEP 703: making the GIL optional

#33

Post by ggm »

Lots of C library code for decades carried man page warnings it was unstable for use in async, re-entrant and recursive contexts. We learned how to cope and incrementally re-entrant safe versions deployed without too much API instability. Maybe time has healed wounds and caused me memory loss of the pain of discovery you'd tripped over them.

String parsing which tokenised in-place. DNS calls which used static buffers. Things which exploited Vax specific stack behaviour.

I think the GIL has been a blessing and a curse.

Re: Intent to approve PEP 703: making the GIL optional

#34

Post by miraculixx »

superjared wrote: post #22
miraculixx wrote: post #16

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…

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

How do you suggest we could teach proper threading (what is that?) to the masses?

Re: Intent to approve PEP 703: making the GIL optional

#35

Post by paulddraper »

n2d4 wrote: post #25
miraculixx wrote: post #16

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…

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 ap…

> this is more common than you think

Like, for example,

  count += 1
---

The GIL primarily protects C code, not Python code.

Re: Intent to approve PEP 703: making the GIL optional

#36

Post by dpedu »

paulddraper wrote: post #31
miraculixx wrote: post #16

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…

Python is already Java but worse. All of the multithreading bugs without any of the multithreading performance.

That's not quite true. For example, most operations on lists and dicts are thread-safe in the current version of python. You can't say that about languages with true multithreading.

Re: Intent to approve PEP 703: making the GIL optional

#37

Post by miraculixx »

valyagolev wrote: post #30

there'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 a…

Well said. Thanks

Re: Intent to approve PEP 703: making the GIL optional

#38

Post by wtetzner »

dpedu wrote: post #36
paulddraper wrote: post #31

Earlier quoted context omitted.

Python is already Java but worse. All of the multithreading bugs without any of the multithreading performance.

That's not quite true. For example, most operations on lists and dicts are thread-safe in the current version of python. You can't say that about languages with true multithreading.

Of course Java has thread safe collections in the standard library. ConcurrentHashMap etc. are popular in multithreaded contexts.

Re: Intent to approve PEP 703: making the GIL optional

#40

Post by valyagolev »

valyagolev wrote: post #30

there'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 a…

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
Post reply on HN