python is removing the GIL! (PEP 703) (advanced) anthony explains
HTML-код
- Опубликовано: 15 авг 2023
- will this be another python 3 disaster? what all needs to change?
- why remove the GIL? • why remove the python ...
- immortal objects in python -- • refcount ONE BILLION? ...
playlist: • anthony explains
==========
twitch: / anthonywritescode
dicsord: / discord
twitter: / codewithanthony
github: github.com/asottile
stream github: github.com/anthonywritescode
I won't ask for subscriptions / likes / comments in videos but it really helps the channel. If you have any suggestions or things you'd like to see please comment below!
If python is removing the GIL means it's not a snek, its a physh.
If it changes so much and makes some things incompatible, they should release it as a new major version Python 4.0
Going from C++ to Python, my first WTF of the language was that my threaded code ran roughly thread times slower, rather than thread times faster. I still can’t believe it’s used as much as it is, but I type it every day.
the reality is Guido didn't really understand threading when he started python, that's normal for 99.9% of engineers. Until you spend a few years writing highly threaded applications, it's just hard to understand.
The irony of python (a snake) removing the GIL (you know, like gills on a fish) is not lost on me these days
Been doing parallel programming and multithreaded in C++ since 1998
a lot of python devs do not care about thread safety, they will never do even when GIL removed. It's a disaster
Just rename the old python Fish.
Because I love writing in Python, but... annoyed that it is too slow for many of my goals, so... I decided to learn just enough javascript (again) for Python to be converted to the nearest I can... instead of using PyGame... NumPy... etc.
Small things are allocated 😂 like an 80 byte integer object 😅
I remember Guido discussing the GIL, basically concluding that it's not easily going to come off (maybe with Lex Fridman?). Now I see why that's the case. So many changes, slow downs and overcomplications of existing code.
Thanks for the explanation!
I agree w/ the pessimistic prognosis, but OTOH, I don't think anybody is expecting this to work right out of the box. I really believe that the benefits from these changes will be seen in around 5 years, maybe less in some cases.
I too think that this wont get a good foothold. However, I do see it as a great learning experience for the developers of python. An experiment that will give them better insight into the issues (and perhaps solutions) to leaving the GIL behind in the future. I also support the release of this as a new major release, or at least an experimental release version. During which time they should leave the current version with the GIL in place clean of all modifications needed to remove the GIL. I don't think removing the GIL and slowing code will kill python, but needing to recompile all those higher performance and long standing C libraries will certainly cause a dip in popularity as many of the long standing C extensions may never be re-compiled!
Seems interesting. I'm worried about slowdowns, but creating it as another "flavor" which can be improved over time is a good move
Maybe you could make another video contrasting this approach with the PEP 684/554 approach of multiple interpreters.
14:10
For what i understand is that Guido will not accept any "gill less" version of Python where "single threaded" code will slow down. So then I would conclude that it depends if this pep can accomplishe this, if this will be implemented in the main version of python.
So are they going to have happened-before ordering or expose memory fences?
Most of the time when I'm using the threading library I'm basically doing tasks that could be handled with async. I suspect a lot of us don't really need to remove the GIL even though we use threading.