On Thu, Oct 11, 2018 at 6:43 PM Thomas Jollans <t...@tjol.eu> wrote: > The gist is that the GIL is a problem only for relatively few problems > (e.g. games that need limited-scale low-latency parallelism). Most of > the time, you either only need one process in the first place, or you > can take full advantage of your multi-core machine, or multiple > multi-core machines, using multiple processes (with ipyparallel or whatever)
Right. If someone goes on a long rant saying how he wasn't able to write his device driver in Python, and he's giving up on the language and going to C, would that be taken as an affront to Python, or the knell of the language, or anything like that? No, it'd be "well, that's not Python's role". But if someone needs to manage a billion teensy sub-jobs and then finds that Python is unsuitable, it's clearly the GIL's fault, and this is a fundamental flaw in the language, and we should all move to Go for all our coding because Python utterly sucks. Why? Why not just let other languages do things differently, and have other design tradeoffs? This is one fairly specific class of problem which is poorly served by Python's/CPython's design. (I'm not sure how much of this could be done differently in an alternative implementation; so far, we haven't seen a "Python for embarrassingly parallel problems" implementation, so I suspect part of it is language design.) So pick a different language *for those problems*. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
