Documenting candidate stdlib modules

The SC had a discussion today with @eric.snow around the topic of PEP 734. We were thinking about ways to get more visibility for modules which are potential candidates for future inclusion in the stdlib. Such modules would be published independently on PyPI first, possibly under a python org[1], maintained under a python repo on GitHub, with documentation published on RTD.

One idea I had was to add a new “category” to the index page which would be something like “Candidate Modules”. Here we could add a page for say subinterpreters which wouldn’t be the actual documentation, but would have useful links such as to the PEP, to the RTD canonical documentation, to the GitHub repo, etc. It might briefly explain what the module is, but it would explicitly not include the full documentation for the module.

We could then theoretically backport this doc page to older Python’s, such as back to 3.12 which is the earliest version of Python that subinterpreters would work on. As @thomas was part of that discussion, I don’t think he was opposed to backporting those candidate module docs to bug fix releases so that even users of Python 3.12 would see it.

In the future, as we work out better guidelines for adding new modules to the stdlib, adding this placeholder page to the “candidates” category would be part of the checklist for getting more visibility to the module, increasing the likelihood that users will try it out, validate the API choices, and give us better confidence about the timing for stdlib inclusion.

Thoughts?


  1. when that’s available ↩︎

10 Likes