Maybe not by the spec, but in practice it’s how it works
1 Like
And that doesn’t include even shade of how much I hate upper-bounds as a distro Python packager.
Let’s not officially distribute software with known bugs, and no intent to let anyone fix them?
IMO it’s very different. By adopting something from Git history, you’re also taking the responsibility to maintain it – even if only for your own needs.
Yeah, okay, I’m remembering how I was persuaded around last time 
Let’s not worry about rehashing all the argument again.
So we don’t want to post the code anywhere ourselves, but can we at least take the standard names on PyPI and put up a link to the last committed version? Something so that people don’t have to dig all the way into these discussions to figure out what they should be doing, and something official looking enough that they won’t worry they’re breaking the rules by doing it.
3 Likes
Why does the name of the package matter? The package can be called whatever you want as long as you don’t change the module name. With the same module name it will still be a plug’n’play replacement of the old stdlib package afaik. So unless there’s something I don’t understand I would just name it something like nntplib-standalone and move on.
4 Likes
We’ve had a number of PyPI packages at the other end of the spectrum - versions of something that’s going into a future Python version, but not already released versions. Those have typically had “backport” in the name. From my limited perspective, those haven’t caused any major headaches (others may have a more negative view). Could we invent some similar tag that implies it’s not official, but will give people more time to move away? “-migration” or “-transitional” maybe?
Yes.
Which is why changing a module from being a part of the standard library (and thus maintained by the PSF), to being on PyPI is such a big deal. PyPI is a much greater security risk than the standard library.
So maintaining the same name for the new, PyPI-hosted modules is exposing people to that additional risk, perhaps without their full knowledge.
I’m not sure what happened, as I can’t seem to find any public mention of it on this thread, anywhere in the PyPI GitHub org, or searching on Google, but after checking again, it seems that despite the multiple serious concerns expressed by the community, rather discouraging comments from the maintainer and a general consensus against it, expressed on the linked thread, that particular continuation of nntplib was in fact handed the original, official name on PyPI after all.
While the potential harms in this particular case is relatively limited, given it the module is for a relatively niche, obsolescent (though still in-use) protocol, other PEP 594 modules like cgi that see vastly more extent use are a whole different story. Therefore, and to be consistent and fair to other such maintainers like @_david who’ve been polite, diplomatic and understanding, we really should openly discuss and decide on a coherent policy in collaboration with the PyPI admins as soon as practical, before this becomes a larger problem.
Therefore, I’ve opened a new thread to discuss this:
Also,
Actually, it seems folks have had enough of a potential problem to open a detailed thread to consider doing something about it (which was prompted by the concerns of a number of Python core devs), as there is a current thread discussing exactly this.
However, the potential problem they pose is much less than in the current situation, as they are generally owned by the core devs and other known and trusted maintainers who developed them, whose work was already accepted into Python’s standard library, rather than by whatever third party happened to express interested in the package first. Furthermore, they will be shadowed in any future Python version that has them in the stdlib and thus serve no future ongoing purpose, whereas particularly if there is significant community interest, these names may remain relevant for many years to come.
1 Like
It looks like the transfer was done prior to any of the comments on this thread (other than the OP and Praydun), the OP emailed admin@ and we released the name.
This leads into your next statement, but AFAIK there’s no real policy on stdlib names on PyPI. We added the automatic block years ago after a bunch of typosquats went up. I dont think we’ve thought about them much beyond that. Probably good to sort out a defined policy.
1 Like