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

41–50 of 513 posts

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

#41

Post by veave »

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…

>Free threading as introduced by PEP 703 is well known to be errorprone, hard to get right and generally advised against, unless you know exactly what you are doing.

You should hear about async...

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

#42

Post by miraculixx »

Waterluvian wrote: post #23

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

I am sure the intent is good. I am not so sure it is possible to avoid. They already say it could take 5+ years of having gil + nogil exist in parallel.

For any tool builder that means their cost has just doubled for the next five years, at least. Why? Because people will want to use tools in either mode, no matter if it is deemed productive or experimental.

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

#43

Post by dpedu »

wtetzner wrote: post #38
dpedu wrote: post #36

Earlier quoted context omitted.

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.

The difference is that it's a language feature in python whereas the java equivalents had to be written with locking or other approaches for handling concurrent access.

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

#44

Post by miraculixx »

veave wrote: post #41
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…

>Free threading as introduced by PEP 703 is well known to be errorprone, hard to get right and generally advised against, unless you know exactly what you are doing. You should hear about async...

Indeed. You should hear my opinions on async (in Python).

;)

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

#45

Post by nyanpasu64 »

miraculixx wrote: post #34
superjared wrote: post #22

Earlier quoted context omitted.

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

Rust is a brilliant lesson in using traditional threading safely. It uses & for thread-shared types and constrains &mut to a single thread, which naturally causes people to keep single-threaded data on an object only accessible from a single thread, and make multithreaded data either immutable, mutex-protected, or atomic.

Alternatively, message-passing isn't traditional threading, but Erlang/Go-style languages are another way to approach concurrency or parallelism.

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

#47

Post by miraculixx »

valyagolev wrote: post #40
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

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's a good thing.

In the future the default concurrency model will be shared everything free threading, and all hell might break loose. Hopefully not.

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

#48

Post by Phil_Latio »

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…

> 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 first language, while Python is my favorite language.

> And Python already has an expert mode - called Cython oer Numba to name just two.

CPython is the "official" Python. How is it beneficial to depend on some 3rd party projects? I don't want to use such projects.

As to the PEP itself: It's optional, with the GIL being enabled by the default. So what's the problem...

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

#49

Post by fbdab103 »

KMnO4 wrote: post #32
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 limi…

At the current implementation, GILless is a performance regression[0], of 5-7%

[0] https://peps.python.org/pep-0703/#performance

Post reply on HN