Up until now, as far as I’m aware names of modules and import packages in the Python standard library are not permitted for new PyPI uploads, in order to protect against the obvious security implications and user mistakes. However, with the PEP 594 mass deprecation and removal of obsolescent stdlib modules, questions have arisen on how to handle third party requests to claim these protected names in order to publish their own standalone versions of these modules, including:
Allow nntplib on PyPI, where a third party developer maintaining a standalone version of the
nntplibstandard library requested ownership of the name be transferred to them. Most community members appeared to not support this and raised a number of significant concerns about transferring the name, some specific to the particular case (notably, the project’s development practices and the maintainer’s discouragingly combative responses to questions and critique), but most focused on the broader issues that this would entail for the removed modules in general. Despite this, while I can’t find any public mention or discussion on the thread, the PyPI GitHub org, or googling it, it seems the name was in fact later transferred to the maintainer in question.
- Handling modules on PyPI that are now in the standard library? discusses the issues with and potential solutions to the inverse case, backport and unrelated/squatter PyPI projects sharing the same names as current stdlib modules still seeing a very high amount of use, years to even over a decade after all supported Python versions include the module . The thread both highlighted how widespread inadvertent installation of such packages is, and also discussed the concerns of allowing such for removed modules more directly.
- PEP 594 has been implemented: Python 3.13 removes 20 stdlib modules presents a detailed summary of the PEP 594 removals and a path forward for modules that the community is still interested in, which both included questions and concerns about the PyPI naming, and also some ideas for how to direct people to third-party replacements without just handing someone the official name.
While the potential harms in the extent example case of
nntplib are somewhat more limited, given it the module is for a relatively niche, obsolescent (though still in-use) protocol, other PEP 594 modules like
cgi that see far more continued use are a whole different story, and we should be consistent and fair to the other maintainers involved who’ve already moved to their own non-conflicting names. Therefore, I believe we really should discuss and decide on a coherent policy in collaboration with the PyPI folks (e.g. @dustin , @EWDurbin and @dstufft ) as soon as practical, before this becomes a larger problem.
Some of the issues with handing out the stdlib names to third-party maintainers include
- The PyPI admins will have to pick and choose who gets permanent ownership of the name based on very limited initial information, which may change over time.
- Using the original, canonical name could cause user confusion over whether the package is official or supported by the core team rather than third party
- There are continuing security (and potential liability) implications with handing out well-known, “official” stdlib names to arbitrary third party maintainers if either any maintainer (or their successors) provide untrustworthy, or their accounts are compromised
- A high volume of devs and users that are likely to attempt to install the package simply based on its name alone (from error messages, or recognition) rather than its quality, with a lower chance of doing their own due diligence like with any other third party PyPI package
By contrast, the downsides of not allowing such are quite limited. As the import module/package name can stay the same, and only the PyPI project name change, it is still just as much a drop-in replacement. Developers and users will still need to actively install/add a dependency on the new PyPI package, they just can’t simply assume that the package with the “official” name of the stdlib module is the “canonical” one they should use and trust. Instead, this would ensure they perform the same due diligence as with any other third-party PyPI package they choose to install/depend on.
Additionally, in the near term to ease migration, the deprecation notices and What’s New announcement of the deprecation/removal can suggest one or more suitable PyPI replacements, if available (as done for
nntplib), which doesn’t require committing to one “blessed” successor in near-perpetuity.
Therefore, I would personally strongly recommend that the names of modules that are removed continue to be protected for at least the immediate future (and the
nntplib name reclaimed as soon as practical to minimize disruption, with the maintainer given sufficient time to move to a new unique name). Should a well-supported popular community-maintained successor to one or more of these modules emerge that retains significant interest over time, and compelling reasons are found to use the stdlib name, then this can always be revisited later.
For example, 6.8 million downloads/mo. for
argparse, added in Python 2.7 in 2010, or 36k downloads/mo.—>96-98% on Python versions >2.7 for which it will error on install due to using the
turtle, a quasi-placeholder unrelated to the stdlib module uploaded on one day in 2009 and never touched again ↩︎