Will multithreading make python less popular?

[Paul Rubin]

Terry Reedy <tjreedy at udel.edu> writes:
> > The slowness itself can be addressed by technical means, such as
> > native-code compilation and eliminating the GIL.
> 
> Given that the GIL remains to make Python run faster in the usual (up
> to now, at least) case of 1 processor, that seems a strange statement.

We've had this discussion before.  The 1-processor slowdown that you
refer to comes from replacing the GIL with the blunt instrument of a
lock around each reference count operation.  That has the advantage of
not breaking CPython in a million places, but has the drawback of
taking a big performance hit.  The long term fix is to replace
reference counts with a tracing GC.  That is apparently not feasible
in the framework of CPython and the many extension modules that have
been written for it, so it would have to be accompanied by an
implementation switch (e.g. PyPy).

Steve Holden has mentioned Jython and Ironpython a few times in this
thread.  Those are reasonable proofs of the concept of a GIL-less
Python, but for various reasons (spelled J-V-M and W-i-n-d-o-w-s) are
not all that suitable for many current Python users.