Personally, I think you’re insisting on too much process here. As @brettcannon pointed out, @pradyunsg is well aware of PyPA processes, and I am also. I suggest you trust us to not mess things up.
Unless you’re requesting as a PyPA member (I’m sorry, I genuinely can’t recall if you are one and I’m not sure how to check) that we put this to a vote. In which case I think it’s unnecessary, but that’s your right, so fair enough.
I don’t think you can. You’d need to check members of Mailman 3 Info | pypa-committers@python.org - python.org (for which you’d need to be admin of that list) or go through each pypa project and check who has a write bit on a project 
Would be nice to have a public list though
Sorry, I didn’t mean to stir up another fuss. I wasn’t suggesting a vote, but rather simply a notification to the PyPA-committers list, such that the other core committers were duly aware of it and had the opportunity to object, which was based on what you stated when this came up on PEP 639:
Is there some other canonical venue for these notifications now (other than >130 posts deep in a discussion thread 
)? If so, I’d be happy to submit a PR to help clarify that in the section you linked.
| hyphen count | package proportion |
|---|---|
| 1 | 60.0% |
| 2 | 39.6% |
| 3 | 0.5% |
None of our internal packages had an underscore _. Our internal index only serves internal packages, the majority of which are prefixed by a disambiguator, followed by a dash -. We use build to build sdists.
So the project names are disambiguator-something? Under this proposal, those would be normalised to disambiguator_something in the sdist name (the same as in the wheel name). I assume that would be OK?
As long as pip will still install them when requesting disambiguator-something and our internal index responds with <a ...>disambiguator_something-42.0.1.tar.gz</a>. I would assume so, considering this is how wheels work.
As there have been no objections, I’ll assume you’re on board and formally submit PEP 625 for approval. @uranusjr I’m assuming based on your previous comments that you are OK with that - please say if that’s not the case.
Let’s do it
Sounds good. Someone should file a PR to mark the PEP as a draft, and add me as the PEP Delegate.
I’ll try and get to a decision on this, by the end of this week. 
Actually, that’s a good point. From some time back:
@uranusjr I’m assuming that you’re happy to drop this requirement (I removed it in my PR to the PEP)
It took me more than a week, but I’m happy to approve this PEP.
I’ve left the PEP as “accepted” at this point. I’ll do a PR to update the formal spec and make this PEP “Final” once that’s been completed.
Spec update at Update sdist spec to reflect PEP 625 by pfmoore · Pull Request #1141 · pypa/packaging.python.org · GitHub
I think we should ensure that it’s implemented in popular build backends, at least setuptools, before we mark this as completed/Final.
Hatchling has always supported this.
I’ve raised [FR] Implement PEP 625 - File Name of a Source Distribution · Issue #3593 · pypa/setuptools · GitHub to track this for setuptools.