What sort of requirements do we want to place on ourselves for adding modules to the stdlib as well as removing them (this is not about what to do with the stdlib in terms of what kinds of modules should be there, etc.)? Clarifying our views on this affects multiple PEPs such as 4, 411, and 594 (and the latter is the reason I’m asking now so that I can help @tiran get that PEP completed and hopefully accepted).
Should all new modules be marked as provisional?
How long can a module be marked provisional? Is there a limit?
PEP 387 guarantees modules get a 2 release deprecation (unless the SC okays it being shorter). Is there anything else to do there?
- Require a PEP for new modules? Yes, because the stdlib is important enough to require a PEPs’ level of exposure and discussion.
- Should all new modules be marked as provisional? Yes, as even for modules that have existed outside of the stdlib will still end up with way more usage and exposure once in the stdlib itself.
- Is there a limit to being a provisional module? Yes, two releases. One for the initial release, and one more to make sure the feedback used to make initial changes are the right thing. Plus it gives slower adopters more time to get exposed to a module.
- Anything else to do for removed modules? No, because we are dropping them for a reason: they aren’t being maintained and/or used enough anymore. Some have suggested copying the modules over to some “dead modules” repo and packaging them up, but that will still require maintenance as that packaging will eventually grow stale (packaging standards are still being created), and the original code as shipped in the stdlib is still available in CPython’s repo history. Plus people can always copy the source into their own project to vendor it or start a fork.
I would also argue that provisional modules should raise a
ProvisionalWarning so that people know they are using something that is subject to change.