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?
I think using a Discourse theme component (Linkify words in post - theme-component - Discourse Meta)
with a linked word entry /pep(?: |-)?([0-9]+)/i, https://peps.python.org/pep-$1
would work.
For example, It should match PEP 434, pep 457, PEP-558, pep596
I’ve had a messy Javascript bookmarklet for years that zero-padded a number and constructed the canonical URL. And now it turns out there’s a shortcut URL that does that for me… Thanks, whoever added that!
(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.)
Is typing really so distinct from the rest of Python that it needs to have its own namespace, er, numberspace for PEPs?
That’s not a rhetorical question. Its a real question.
If typing is just another feature, than perhaps it doesn’t need to be separated out from the regular PEP number space. But if it is sufficiently distinct, maybe it should be.
The Python3000 transition was kinda special, but should we treat it as precedence for other categories? Also not a rhetorical question. Perhaps we need a hierarchy of PEP number spaces for, let’s say:
typing
maths and numerics
Unicode
performance
etc? But what happens when a PEP relates to two or more of these categories?
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.
