Sorry for the delay in response. So we actually *do* disallow package names with the same name as stdlib modules, however because there are a number of them that exist today and are useful (asyncio, ssl, etc) the way we’ve implemented this is that *new* projects cannot be created with the same name as stdlib modules, but existing projects can continue to use their names. This also allows the PyPI admins to selectively give someone the same name as a stdlib module if needed.
Just to close the loop on this, I believe the ones identified here have all be removed from PyPI along with several others by the same author. If you come across any others feel free to point them out. > On Oct 20, 2017, at 1:44 PM, Erik Bray <erik.m.b...@gmail.com> wrote: > > Hi all, > > Sorry if this has come up before--I don't remember if it has. A recent > question on StackOverflow [1] alerted to me to the fact that there is > a package named "os" on PyPI: https://pypi.python.org/pypi/os > > *Thankfully* it is: > > a) Malformed--the package tarball isn't built correctly and it doesn't > install with pip > b) Not (currently!) evil: It just raises a RuntimeError telling you > not to "pip install os" > > That said, I think such packages should be prevented from being > uploaded at all. Naturally, the list of stdlib modules is a moving > target, but not *that* fast-moving. > > Conversely, I don't think new modules added to the stdlib should use > the name of a package on PyPI, or at least should be prevented from > being uploaded for Python versions equal to or later than the version > in which that module was added to the stdlib. > > Thanks, > Erik > > > [1] > https://stackoverflow.com/questions/46853112/python-pip-install-os-windows-errno-2
