Eric Snow

> What happens if we remove the GIL? The [nogil ](https://github.com/colesbury/nogil/) branch is taking shape very nicely. Yeah, that's a neat project. There shouldn't be any significant conflicts in the...

> The real objective with per-interpreter GIL is maximum isolation between interpreters Hmm, maybe the PEP should emphasize isolation rather than the GIL...

https://github.com/python/peps/pull/2387

https://github.com/python/cpython/pull/31771

That's really useful information, @idahogray. That's really interesting. I read through a short explanation of BEAM concurrency (and parallelism), oriented toward implementation rather than the programming model. It sounds like...

FYI, here's a recent breakdown of the remaining globals: * core/builtins (651 total) + 298 static types (incl. 130 exception types) + 179 cached objects (e.g. str instances) + 57...

Extension authors would definitely benefit from more documentation on best practices for interacting with the C-API. A dedicated page in the official Python docs on how to take advantage of...

The key detail is that there is a "main" interpreter: * created during runtime initialization * used during runtime initialization * used during runtime finalization * the initial interpreter exposed...

FYI, the [C-API docs have a paragraph](https://docs.python.org/3/c-api/init.html#sub-interpreter-support) explaining the distinction (thanks to @nanjekyejoannah). @markshannon, do you think it would help to have more detail there? (IMHO, there isn't much more...

(Sorry, I missed this.) > Removing it from the C-API would be a major compatibility break – one that I think Python should not make. How bad would it be...