On Tue, Apr 21, 2020 at 8:54 AM Paul Moore <p.f.moore@gmail.com> wrote:
On Tue, 21 Apr 2020 at 15:31, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Here are the options for handling non-compliant extension modules:
1. do nothing (extensions may break in ways that are hard for users to deal with) 2. raise ImportError if an extension without PEP 489 support is imported in a subinterpreter 3. add a per-interpreter isolated mode (default) that provides the behavior of #2, where non-isolated gives #1
At this point my plan was go with #2, to avoid giving extension authors the pain that comes with #1. If we went with #3, at least during the provisional phase, it would allow extension authors to try out their extensions in subinterpreters.
This seems sensible to me - #2 ensures that we don't get weird bugs from users trying things that we know they shouldn't be doing. I'm not sure how much advantage #3 would have, presumably extension authors wanting to "try out" subinterpreters would at some point have to mark them as importable as per #2, so why not just do that much and then see what else needs changing?
Good point. I suppose the main difference is that they (and their users) could try the extension under subinterpreters without needing a separate build.
But I don't know the C API for subinterpreters, so maybe there are complexities I don't understand, in which case having #3 probably makes more sense in that context.
There aren't any extra complexities. Per PEP 489 [1], in a module's init function you call PyModuleDef_Init() on its PyModuleDef and the return it. The import machinery does the rest. The subinterpreter C-API is not involved. -eric [1] https://www.python.org/dev/peps/pep-0489/