On Tue, Apr 21, 2020 at 8:54 AM Paul Moore <p.f.mo...@gmail.com> wrote: > > On Tue, 21 Apr 2020 at 15:31, Eric Snow <ericsnowcurren...@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/ _______________________________________________ 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/ACYSACREHESNOUIJLXZLRZUBORZ4Q7GS/ Code of Conduct: http://python.org/psf/codeofconduct/
