On Tuesday, April 21, 2020 9:20 AM Victor Stinner [mailto:vstin...@python.org] wrote > Hi, > > Le sam. 18 avr. 2020 à 19:16, Antoine Pitrou <solip...@pitrou.net> a écrit : > > Mostly, I hope that by making the > > subinterpreters functionality available to pure Python programmers > > (while it was formally an advanced and arcane part of the C API), we > > will spur of bunch of interesting third-party experimentations, > > including possibilities that we on python-dev have not thought about. > > (...) > > * I think the module should indeed be provisional. Experimentation may > > discover warts that call for a change in the API or semantics. Let's > > not prevent ourselves from fixing those issues. > > Would it make sense to start by adding the module as a private > "_subinterpreters" module but document it? The "_" prefix would be a > reminder that "hey! it's experimental, there is a no backward > compatibility warranty there". > > We can also add a big warning in the documentation. > > Victor
What about requiring "from __future__ import subinterpreters" to use this? According to the docs, the purpose of __future__ is "to document when incompatible changes were introduced", and it does seem that this would be an incompatible change for some C extensions. --Edwin _______________________________________________ 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/N357K6CNGLKWILZYTZUTCIHSS2IEEEXG/ Code of Conduct: http://python.org/psf/codeofconduct/
