Steven D'Aprano <steve+comp.lang.pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list