Fair enough;the distinction is subtle. Python uses native system threads and of course such threads are scheduled by the OS. But in practice, the GIL allows only one thread to run at a time unless the GIL is subverted via C extensions or similar. I get why this is, given Python's architecture and the legacy of the GIL (which dates to the late 90s, when multicore machines were relatively rare and expensive).

But it's still not the case that multiple threads "normally" run in parallel, with the OS ensuring fairness, which is what (I think) most programmers would expect threads to do in a general-purpose threaded language.

It simply isn't true that "the GIL allows only one thread to run at a time."

"Note that potentially blocking or long-running operations, such as I/O, image processing, and NumPy number crunching, happen outside the GIL. Therefore it is only in multithreaded programs that spend a lot of time inside the GIL, interpreting CPython bytecode, that the GIL becomes a bottleneck."

The sky isn't falling, in the worst possible case you can still use Jython or whatever

Right, that's why I qualified my statement with ...unless the GIL is subverted via C extensions or similar.

The sky isn't falling, in the worst possible case you can still use Jython or whatever.

Sigh. I could port to C++ or whatever, too.

The entire interpreter is written in C. Using facilities written in C, as documented, is not "subverting" anything. That's ridiculous hyperbole and it really doesn't help your credibility.

"unless the GIL is subverted via C extensions or similar."

I would hardly call I/O with Python built-in functions to be a subversion of the GIL.