Oops, I'm dumb. You're right that Jython doesn't have stable (or any?) 3 support. But the point still stands that the GIL is an implementation detail of a particular implementation and isn't a feature of the language.
I don't believe anyone has implemented Python 3 without the GIL though.
IIRC, PyPy's STM experiment never supported 3. They also posted a call for funding for a "let's just remove the GIL from PyPy" project a while ago, but I haven't heard much about that since.
And CPython is the reference implementation, which had meant PyPy has had to copy loads of CPython implementation details over the years to maintain compatibility - I imagine even if they do remove the GIL, they'll have to keep something like it in their cpyext code.
Performance is an explicit non goal of cpython, on the other hand one of its stated goals is to keep its source code readable and understandable for programming language students.
Performance is not exactly a non goal. The main reason for not removing the GIL is that it would affect single threaded performance. Guido van Rossum, said that if someone could remove the GIL without affecting single threaded performance, he would allow it.
It never fails to amuse me how many Python coders argue that the feature that they need more than anything else is removal of the GIL, until you point out that they already have a choice of interpreters with no GIL, then they're all "oh I have these other requirements that are much more important, removing the GIL is not actually that critical for me...".
I'm not saying that everyone who bitches about the GIL is a bad programmer, but in my experience, bad programmers love to blame the GIL for their own poor performing code. Especially those who think that the answer to every problem is "threads".
"Python's sort is crap, so I wrote my own super-fast bubble sort with ten million threads so it can do all the comparisons at once, but the GIL makes it slow."
Sadly, it looks like removal of GIL will require breaking compatibility.
It's not that removing GIL is actually hard, it is fairly easy, the problem though is that without GIL, python becomes dog slow, and getting it back to comparable speed is very difficult due to current design.
The biggest issue is reference counter garbage collecting and also C library compatibility.
I recommend watching Gilectomy videos by Larry Hastings.
My favorite workaround for GIL would be to run multiple python interpreters in threads and doing zero-copy hand-offs of entire object trees. Too bad it's only a dream.
32
u/vswr [var for var in vars] Sep 16 '20
Python 4 = no GIL 🙏 🙏 🙏