__future__ imports only have effects on the parser and compiler. PEP 554 is mostly a Python module, currently named "_xxsubinterpreters". Victor Le mar. 21 avr. 2020 à 15:37, Edwin Zimmerman <edwin@211mainstreet.net> a écrit :
On Tuesday, April 21, 2020 9:20 AM Victor Stinner [mailto:vstinner@python.org] wrote
Hi,
Le sam. 18 avr. 2020 à 19:16, Antoine Pitrou <solipsis@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
-- Night gathers, and now my watch begins. It shall not end until my death.