STINNER Victor <vstin...@python.org> added the comment:
> Instead of passing `_PyRuntimeState` around everywhere, why not just let it > disappear in time. Passing runtime (_PyRuntimeState) is a temporary move until more and more fields are moved from _PyRuntimeState into PyInterpreterState. I just created bpo-39984 "Move some ceval fields from _PyRuntime.ceval to PyInterpreterState.ceval" yesterday ;-) Once we will manage to move the GIL into PyInterpreterState, we would still have to pass PyInterpreterState or PyThreadState to function which require to access the GIL. Passing explicitly runtime is a first step to prepare to migration to PyInterpreterState or PyThreadState. My intent is to show that many functions rely on "global variables": pass these variables instead. If you are thinking about getting the current Python thread state using a thread local storage, that's a different topic and I'm not aware of an open issue to track this idea. > Currently `_PyRuntimeState` manages "global" state, mainly the GIL and some > config. Once the GIL has been migrated to the sub-interpreters, the config > part can be factored out and `_PyRuntimeState` can just disappear. I don't think that we will be able to fully remove _PyRuntimeState. It seems like the PEP 554 "Multiple Interpreters in the Stdlib" requires a registry of interpreters and it currently lives in _PyRuntimeState. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36710> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
