miraculixx

18 ms·

91.
by miraculixx 3y ago
There will be 5+ years of parallel gil/nogil builds. Every library developer will have to deal with this at some point.
92.
by miraculixx 3y ago
Yes bc they fear a Py3 to 4 transition would be perceived as a major burden. I'm afraid we'll soon learn its not the version # that's burdensome, but the real or perceived(!) incompatibility between versions. I wonder if intr
93.
by miraculixx 3y ago
I have the same impression though I think its not intentional or otherwise ill intended.
94.
by miraculixx 3y ago
His leadership & decision arbitration is dearly missing. Now we have decide by committee and as a result we see Python being pushed and pulled in all directions.
95.
by miraculixx 3y ago
It sure did. Also the decision was pretty much rushed through, if you follow the latest discussion (which got shut down on the notion that everything has been said and trust the SC and coredevs). https://discuss.python.org/t
96.
by miraculixx 3y ago
From the POC implementation the reports state ~5-7% if memory serves right.
97.
by miraculixx 3y ago
Indeed!
98.
by miraculixx 3y ago
Right about ~2033
99.
by miraculixx 3y ago
Nice! ;)
100.
by miraculixx 3y ago
This requirement could have been well served with a gil per thread and arena based (shared) object allocation model. Every other use case would have been unaffected. Now we change the world for everyone and put most of library developers th
101.
by miraculixx 3y ago
Yes they will benefit from this. Unfortunately most everyone else will suffer.
102.
by miraculixx 3y ago
You would be well served with arena based (shared) object allocation and a gil per thread model. No need to draw everyone else into this.
103.
by miraculixx 3y ago
Yes, the same is true for free threading. Yet people assume free threading is free concurrency and that's the problem.
104.
by miraculixx 3y ago
> The GIL doesn't prevent race conditions between individual python instructions Yes it does. Unless we mean something different?
105.
by miraculixx 3y ago
Progress in the name if progress is rarely a good choice. The key question that remains unanswered is Why should Python even need a free threading model? There are no good answers afaik.
106.
by miraculixx 3y ago
Threads can end in limbo too. At least with multiprocessing you get to kill those that hang. Threads, not so much.
107.
by miraculixx 3y ago
Especially PyCharm with its endless indexing. Have the time its key features are not available bc it has decided to go on another indexing spree. Alas that's for another thread ;)
108.
by miraculixx 3y ago
This. Python had a unique stance, it was different for a good reason. The seamingly endless attempt to become more likeable to yet another subgroup of needs is not a good development. It started with static typing, it continued with async,
109.
by miraculixx 3y ago
> They are being introduced because a way to get true thread-based parallelism in Python has been one of THE top priority demands of a huge part of the Python Where is this demand exactly? We hear a lot of complaining but very often this
110.
by miraculixx 3y ago
Thanks for this. I'll read up on that. Any good links pointers to start?
111.
by miraculixx 3y ago
Here's what's puzzling me about this: Why then is there even a need for a seperate nogil build? If it is like this says, wouldn't it be easier to just make the standard build switch to gil or nogil automatically (or honor the
112.
by miraculixx 3y ago
Thanks. Glad to know now!
113.
by miraculixx 3y ago
It's not about the API. The multithreading API (in any language) is easy: 1. Start a thread 2. Give it work to do (data + code) The problems start when multiple threads work on the same data and compete for the same system resources. A
114.
by miraculixx 3y ago
I agree, actually. It's just that (some) people really want multithreading. And with that Python had the rare chance to say, ok you'll get it, but we will make it safe by default. Now they said ok you get it, even though it's
115.
by miraculixx 3y ago
Is it success though?
116.
by miraculixx 3y ago
At the end of the day,this is the very point the SC and core devs are ignoring in their decision. They do recognize the impact on the ecosystem will be huge, they recognize there will be at least 5 years of parallel gil/nogil versions(
117.
by miraculixx 3y ago
* removed comment as it was factually false *
118.
by miraculixx 3y ago
Where can I read up on this planned way of working? This is not what the PEP says
119.
by miraculixx 3y ago
I was called inconsiderate for essentially asking this very question. I still think it's the right question to ask: Why should Python even have a free threading model?
120.
by miraculixx 3y ago
The intent is to make no GIL the default eventually.

More ›