On 16. 12. 21 12:33, Antoine Pitrou wrote:
On Tue, 14 Dec 2021 10:38:25 -0700
Eric Snow <ericsnowcurren...@gmail.com> wrote:
So we (the core devs) would effectively be requiring those extensions
to support subinterpreters, regardless of letting them opt out. This
situation has been weighing heavily on my mind since Nathaniel brought
this up. Here are some ideas I've had or heard of about what we could
do to help:
* add a page to the C-API documentation about how to support subinterpreters
* identify the extensions most likely to be impacted and offer to help
* add more helpers to the C-API to make adding subinterpreter support
less painful
* fall back to loading the extension in its own namespace (e.g. use ldm_open())
* fall back to copying the extension's file and loading from the copied file
* ...
As a data point, in PyArrow, we have a bunch of C++ code that interacts
with Python but doesn't belong in a particular Python module. That C++
code can of course have global state, including perhaps Python objects.
What might be nice would be a C API to allow creating interpreter-local
opaque structs, for example:
void* Py_GetInterpreterLocal(const char* unique_name);
void* Py_SetInterpreterLocal(const char* unique_name,
void* ptr, void(*)() destructor);
Then in extension code you'd be able to write, e.g.:
What's the reason these can't be tied to the module?
(As the author of PEP 630, which argues that module state is the best
default place for this kind of mutable "globals", I'm interested in the
cases where it isn't so.)
How do you ensure these Python objects are destroyed by/before
Py_Finalize()? (If you do that -- I realize it's not something people
typically think about.)
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/QUHYVSXGQHXONLRLZNOMH5VMRS44PHPO/
Code of Conduct: http://python.org/psf/codeofconduct/
