Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

the GIL was not removed or at least a solid parallelism story was not included

Not for lack of trying. People have been trying to do this since at least python 1.4. They just haven't found a way of doing it without negatively affecting single threaded performance, which Guido considers an unacceptable trade-off. http://pyparallel.org is probably the most interesting latest experiment in this field, but it never got cross platform support and seems to have stalled out.



They were breaking many things, maybe they should have rewritten the C API? From what I remember that's the blocker.

That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.


The C api isn't the blocker for removing the GIL. The blocker is that Python is a dynamic language and there is no good way to know if another thread has just changed the underlying function on an object or not without having fine grained locking.

Fine grained locking works, but is expensive for non-multithreaded applications and slows down Python. It would speed up multithreaded applications though.


They did break all C extensions in py3k -- not so bad you can't work around it with some preprocessor magic but break it they did.

And they continued to break them within the py3k lifetime, mostly unicode related stuff from what I can remember. Probably still break stuff but I haven't had time for my toy python projects in a while so haven't been messing with the C-API lately.


We're actually agreeing here, I think.

I wished they had broken everything harder and once and for all, in order to fix the issue.

If there's going to be breakage anyway, people adjust their expectations. The scale is basically:

a lot of breakage > a bit of breakage >>>>>> no breakage.

Once you do break backwards compatibility, you might as well do it in a big way, provided you:

* don't offer vaporware for a decade (hello Perl 6!)

* try to offer some mitigations for the migration pain (auto-conversions, support libraries, top-notch docs, etc.)

* offer a great carrot at the end of the tunnel (good performance would be such a carrot)


Here's a video and HN thread that covers most of the current problems with removing the GIL:

https://news.ycombinator.com/item?id=11842779




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: