281–290 of 513 posts
Ruby could learn a lot once this is done, but at the moment GIL optional in python seems to be a 2030 goal.
Earlier quoted context omitted.
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 an…
Qt signals/slots across threads is also message passing. Transparent to boot. Too bad you need to afford a lawyer on retainer to use it these days.
Exciting. Python is mostly written as C shared libraries that knew they had a global lock to rely on. Some of those do sufficiently simple things that they can run without any locking and all will be fine. Others will still need locking, but are now under pressure to run without the gil. Some of those are going to do DIY locking within their own bounds. Maybe what python has really been missing all these years is loa…
Many libraries have never had a multi-processing use case, others are so big that bugs are bound to happen, many of them subtle, so one guaranteed outcome will be unreproducible complaints and devs throwing in the towel. Opt-in will make people unhappy.
Earlier quoted context omitted.
I don't think this is true. There are fairly strong voices on both sides inside the community, at this time it's pretty uncertain. To quote Guido: >Let’s not blow it this time. If we’re going forward with nogil (and I’m not saying we are, but I can’t exclude it), let’s make sure there is a way to be able to import extensions requiring the GIL in a nogil interpreter without any additional shenanigans https://discuss.p…
The Steering Council said their intention is to remove the GIL-build in future: > Long-term, we want no-GIL to be the default, and to remove any vestiges of the GIL (without unnecessarily breaking backward compatibility). We don’t want to wait too long with this, because having two common build modes may be a heavy burden on the community (as, for example, it can double test resources and debugging scenarios), but we…
Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stu…
This seems somewhat delayed, and it may be considered too little, too late. Python community had the chance to leapfrog and embrace alternative concurrency abstractions, such as go routines etc, but it appears that this opportunity was not fully utilized. After enduring the arduous process of migrating from Python 2 -> 3 and navigating the complex world of dependencies, my hope is that we won't encounter another nigh…
I know they say specifically that they don't want a repeat of the Python3 transition scenario, but the approach they're taking now still veers eerily close to that path, at least it looks that way to me. A lot will depend on the Python community and the distribution channels. I could see the community struggling to adopt it in a timely fashion, or distributions jumping the gun (Ubuntu, Fedora, Anaconda). Maybe it's t…
They say they want no-gil to be the only build mode 5 years from when it becomes available. That is both too long and too short. That is too long for Python to have 2 modes. Half a decade is more than enough time for 2 modes to become the status quo. For one thing, think of all the outdated Stackoverflow threads that will be hanging around after that 5 years. I am not optimistic that 5 years won't turn into 10 years…
Developers are lazy. Most people will just do nothing until, 5 years from now, some blog post will go "oh, next month we switch noGil as default, good luck!". At that point everyone will scramble, rush out buggy releases, and spend 5 years finding all the problems.
Is it really too late to not do this ? The only reason to get rid of the GIL is to help threading, but that's not a thing we should be doing. Threads need to just die, and be replaced by something less idiotic. Seriously, having the CPU run fragments of your program at random, so that all the previously ordered pieces are now contending with each other and even themselves ? How can anyone not see that this is the stu…
Please tell us: What other solution do you propose for running CPU bound workloads in parallel?
There are exactly 2: Multiprocessing and using another language.
Earlier quoted context omitted.
I remember scouring those C runtime docs, for every non-reentrant function. It might be what got me in the habit of checking docs when using some API that I know moderately well, just in case there's some important detail I missed before, or something had changed. Around that time, doing cross-platform C++, I got an early look at Java, with concurrency built in from the start, along with GC and various other nice fea…
> originally was an embeddable extension language Python was originally a teaching language, to replace BASIC and Pascal for kids and beginners. (Yes, there once was a time when people took teaching programming seriously.)
> The letter “B” was chosen because it is the first letter of the word “beginner” and because the project was meant to become a language for teaching programming to absolute beginners.
[1] https://inference-review.com/article/the-origins-of-python