On Tue, Apr 21, 2020 at 2:09 AM Antoine Pitrou <solip...@pitrou.net> wrote: > > On Mon, 20 Apr 2020 15:30:37 -0700 > Nathaniel Smith <n...@pobox.com> wrote: > > > > tl;dr: accepting PEP 554 is effectively a C API break, and will force > > many thousands of people worldwide to spend many hours wrangling with > > subinterpreter support. > > For the record, that's not my reading of the PEP. PEP 554 doesn't > mandate that C extensions be rewritten to be subinterpreter-compliant. > It makes that an ideal, not an obligation.
They would not have to be rewritten, unless they want to be used in subinterpreters. The PEP does not say this explicitly. 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. -eric _______________________________________________ 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/E4456ZIXUK7O2QZ4DJETMKTSFYADFL7B/ Code of Conduct: http://python.org/psf/codeofconduct/
