Hi Eric,
Thank you again for coming to the Steering Council’s office hours to discuss PEP 734. We all found it very helpful to talk about the PEP with you in real time.
After much discussion, the Steering Council thinks that the best way forward with this module is to maintain it separately for now, release it on PyPI, and let it mature there for a while before including it in the stdlib. There are several reasons leading us to this decision.
We think the API needs more real-world usage before it can be deemed stable. It may indeed be the best API available, but without some maturation on PyPI, we can’t really know for sure. With the module being independently developed and released, its API can evolve much more quickly than it can once the module is in the stdlib. It will also not have to adhere to the strict backward compatibility and deprecation rules of the stdlib. The Steering Council thinks this is a good policy in general for new stdlib packages, and plans to propose this as “standard operation procedure” for most new packages.
You expressed a concern about the maintenance burden of a PyPI release, but we think that’s solvable. You should be able to recruit co-maintainers, either from the current cohort of core developers, or from users of the subinterpreters package. We’re also confident that we can get help with setting up any automation needed for testing and releases. It shouldn’t be much more of a burden developing and releasing it independently for now than it would be in the stdlib.
We are going to mark the PEP as Deferred, and we can always reevaluate stdlib inclusion for a future version of Python.
Cheers,
-Barry (on behalf of the Steering Council)