Quick, you have ten seconds to figure out which out of these PEP numbers corresponds are related to Typing.
484, 498, 511, 591, 594, 646, etc.
… I know, right? It’s hard.
As a larger point, I think Typing taken as a category of Python is large enough to warrant a more methodical improvement process. It’s overwhelmingly clear that the majority of the community is interested and a lot of the community is invested deeply into the Typing ecosystem, usage of its features, and development of its future.
What I’m proposing is the beginning of a larger conversation about how exactly to organize all the PEPs related to Typing, going forward.
My humble contribution to that hypothetical conversation:
Let’s just have them be TYP-001 and so on. We can start with PEP484, and just update the PEP page to include the new link to TYP-001, and carry that on with the existing Typing PEPs. Then, going forward, the PEP-space can be less cluttered, and the TYP-space will be an easy way to access all Typing-related information/documentation without scouring a bunch of different PEP numbers.
The obvious obstacle is that this sets a precedent against a process that’s now several decades old, for a single aspect of the language and its ecosystem, which is multifaceted. I’m not entirely sure this actually matters, but I feel confident that there will be a lot of strong opinions about it. Personally, I think thoughtful changes to increase the organization and collectedness of PEP knowledge is a net good.
Okay, but, just as quickly: Which of these PEP numbers define language syntax changes? 434, 457, 558, 596, 654…
PEP numbers don’t really mean much on their own. That’s why we have PEP 0 to help out. So there are two solutions here:
Whenever people talk about a PEP, always give the title, not just the number. This could be technologically-assisted if people are consistent about using a strict format like “PEP 257”, which could then be programmed into tools like Discourse to automatically link to the latest version of it.
Categorize PEPs using topics. In the specific case of typing, we already have that, but this could possibly do with some better visibility (did you know about that listing, @wrq?).
Anyone know enough of Discourse functionality to be able to speak to the feasibility of the first option?
(It would be nice if usability features like this were publicised better, or at least documented somewhere. But I don’t want to be ungrateful - it’s quite possible that neat features like this wouldn’t exist at all if whoever added them had needed to mess around updating docs etc.)
Packaging is the other community with its own group of PEPs. The packaging community has its own variation on the standard PEP process (our own standing PEP delegates, a packaging-specific process, etc), and we’re currently OK with just having a specific PEP category.
Maybe there’s a case for completely separating the different types of PEP, but there’s a lot of overhead (new URLs, for example) and not that much obvious benefit. As has already been noted, PEP numbers have no particular meaning in any case (they are just assigned sequentially) so the real issue here is people quoting just numbers without any identifying details. Which is like any other case of community specific jargon - someone in the packaging community knows what “PEP 517” means, and someone in the typing community probably knows what a “covariant type” is. But neither term is particularly meaningful to the general public without looking it up.
No worries, it’s neat that you find them useful and say nice things about it, and helps motivate us to keep working on things like that (and documenting them better). And to be honest, 90% of it was just discussing and debating the implementation, such that at least a brief docs mention a couple of places so that people could more easily make use of it, is surely a reasonable ask for at least a followup.
And to note for others (as you of course were a part of it), it was the original impetus for adding the Topic header and indices on the PEP site, with Typing (and Release PEPs) being a natural and expected extension.
+1 to everything you said above, of course. Having a dedicated sequence of numbers, or a dedicated prefix, or a dedicated site makes it easier to tell if a given arbitrary-numbered PEP is a typing PEP given only the number and not the name or any context, but that’s not often the real issue in practice, as opposed to having a a way to see all the typing PEPs and only the typing PEPs, which is exactly what the topic page already does.