[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: @arigo, thanks for nudging us here. :) Let me know if there's anything else that would help here. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: New changeset d2fdd1fedf6b9dc785cf5025b548a989faed089a by Eric Snow in branch 'master': bpo-36124: Add PyInterpreterState.dict. (gh-12132) https://github.com/python/cpython/commit/d2fdd1fedf6b9dc785cf5025b548a989faed089a --

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: Also, while PyThreadState_GetDict() is the inspiration here, we don't have to copy it exactly. For instance, PyInterpreterState_GetDict() takes a PyInterpreterState* argument, whereas PyThreadState_GetDict() takes no arguments and gets the PyThreadState* from

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: On Sat, Mar 2, 2019 at 12:33 AM Armin Rigo wrote: > PyModule_GetState() requires having the module object that corresponds > to the given interpreter state. I'm not sure how a C extension module is > supposed to get its own module object corresponding to the

[issue36124] Provide convenient C API for storing per-interpreter state

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36124] Provide convenient C API for storing per-interpreter state

Petr Viktorin added the comment: PyModule_GetState() gives you *per-module* state, not per-interpreter state. Module objects are shared across subinterpreters, unless you use multi-phase initialization. > PyModule_GetState() requires having the module object that corresponds > to the given

[issue36124] Provide convenient C API for storing per-interpreter state

Armin Rigo added the comment: PyModule_GetState() requires having the module object that corresponds to the given interpreter state. I'm not sure how a C extension module is supposed to get its own module object corresponding to the current interpreter state, without getting it from the

[issue36124] Provide convenient C API for storing per-interpreter state

Change by Eric Snow : -- assignee: -> eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36124] Provide convenient C API for storing per-interpreter state

Change by Eric Snow : -- keywords: +patch pull_requests: +12135 stage: needs patch -> patch review ___ Python tracker ___ ___

[issue36124] Provide convenient C API for storing per-interpreter state

Change by Eric Snow : -- nosy: +petr.viktorin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: Thinking about this, what is the key difference with the existing PyModule_GetState() function? Is it just the return type (module-defined void * vs. a regular dict)? Certainly it provides a C-only namespace that all extensions can share (like

[issue36124] Provide convenient C API for storing per-interpreter state

Eric Snow added the comment: +1 from me @Armin, thanks to Nick I understand your request better now. I'll put up a PR by the end of the week if no one beats me to it. -- nosy: +arigo, eric.snow ___ Python tracker

[issue36124] Provide convenient C API for storing per-interpreter state

Change by Nick Coghlan : -- stage: -> needs patch type: -> enhancement versions: +Python 3.8 ___ Python tracker ___ ___

[issue36124] Provide convenient C API for storing per-interpreter state

New submission from Nick Coghlan : (New issue derived from https://bugs.python.org/issue35886#msg336501 ) cffi needs a generally available way to get access to a caching dict for the currently active subinterpreter. Currently, they do that by storing it as an attribute in the builtins