Python implementations naturally don't have any GIL in regards to JVM or CLR variants, there is no such thing on those platforms.
YAML and JSON have both tried to replicate the XML tooling experience, only worse.
Schemas, comments, parsing and schema conversions tools.
My mistake, as I assumed they took the same decision as jython and IronPython.
https://jython.readthedocs.io/en/latest/Concurrency/#no-glob...
https://wiki.python.org/moin/IronPython
The difference between JVM, CLR and C in regards to parallel and concurrent code is that they are built for those kind of workloads, and have a memory model proper, hence not needing a GIL.
I think they would have to here, to support native modules. Jython (and I believe IronPython, but don't quote me) does not support native CPython modules. CPython modules explicitly control the GIL, so if they are supported (as they are here), you can't really leave the GIL out without exposing potential thread safety issues.
"PEP 703 – Making the Global Interpreter Lock Optional in CPython" (2023) https://peps.python.org/pep-0703/
CPython built with --disable-gil does not have a GIL (as long as PYTHONGIL=0 and all loaded C extensions are built for --disable-gil mode) https://peps.python.org/pep-0703/#py-mod-gil-slot
"Intent to approve PEP 703: making the GIL optional" (2023) https://news.ycombinator.com/item?id=36913328#36917709 https://news.ycombinator.com/item?id=36913328#36921625
CPython does not have a GIL Global Interpreter Lock GC Garbage Collection phase with --gil-disabled. GraalVM does have a GIL, like CPython without --gil-disabled.
How CPython accomplished nogil in their - the original and reference - fork is described in the topical linked PEP 703.
I think GraalPython does have a GIL, see https://github.com/oracle/graalpython/blob/master/docs/contr... - and if by "there is no such thing on those platforms" you mean JVM/CLR not having a GIL, C also does not have a GIL but CPython does.