Future of Pypy?

[Marko Rauhamaa]

Steven D'Aprano <steve+comp.lang.python at pearwood.info>:

> Yes, but my point is that if some other way solves the problem, then
> you should *use that other technique* rather than complain about the
> GIL. The GIL is not a bottleneck if you can bypass it.
>
> I can sympathize with somebody who says "I have this problem that can
> only be solved with threads, anything else is too difficult, but the
> GIL makes it too slow".
>
> But I don't sympathize with somebody who says "I have this problem
> that can be solved with threads or multiprocessing, but I insist that
> only threads can be used. And now the GIL makes it too slow. Python
> sux."

I'm as "antithread" as anybody, but I think you are blaming the victim
here. I do sympathize with a person who wants to use threads and finds
out there is no true parallelism.

GIL is a downside you have to accept when using a language like Python
that has to "hold the world still" while it's manipulating its data
structures in a safe way. Because of the dynamism involved, effective
parallelism is difficult to achieve.

I must say I have never been bitten by this problem because I only use
threads under duress (occasionally when dealing with blocking APIs) and
because I have very modest performance requirements for Python. For
anything that needs to be fast, I use other programming languages.
Currently, my work is maybe 45% bash, 45% Python and 10% C/C++ (and even
in my C code, I generally steer clear of threads).


Marko