Pep 613 / Pep 484 - specify scope restrictions and inference rules for type alias vs variables

[nipunn1313]

Alternate (improvement) to #2154

PEP 484: Specify inference rules for type alias vs variables
PEP 613: Eliminate scope restriction of explicit TypeAlias

Per discussion on typing-sig
https://mail.python.org/archives/list/typing-sig@python.org/thread/CGOO7GPPECGMLFDUDXSSXTRADI4BXYCS/

[gvanrossum]

While in the past we've allowed updating PEP 484 in minor ways, this goes against the spirit of PEPs (which aren't quite as immutable as Internet RFCs but still shouldn't be rewriting history), I think this is going too far. Honestly I think it's too much even for PEP 613, but that one is much less set in stone.

[JelleZijlstra]

The trouble is that we don't really have an alternative place to document typing changes that seem too small for a new PEP—perhaps https://docs.python.org/3.10/library/typing.html#type-aliases, but that tends to be too concise for a specification. I was hoping that we could add a sort of living spec to typing.readthedocs.io where we could make changes like this (with the consensus of the typing community).

[warsaw]

I was hoping that we could add a sort of living spec to typing.readthedocs.io where we could make changes like this (with the consensus of the typing community).

What about adding something (or moving this documentation) to the Python HOWTOs. It might be more discoverable that way.

[nipunn1313]

Would it be more in-the-spirit of peps to have amendments to the PEP be possible in a more append-only manner?

Such that the amendments always happen at the bottom of the PEP in a way that clearly denotes when the update happened - and what is new.

I think it would achieve the goals that immutability is trying to achieve - namely no surprise changes to the text in the middle of a PEP.

[warsaw]

Would it be more in-the-spirit of peps to have amendments to the PEP be possible in a more append-only manner?

It would be a new "feature" of PEPs. PEPs are not supposed to be the living documentation for a particular feature, so I'm not sure that's the right way to go about it.

[gvanrossum]

Some more thoughts here.

For static type checking in particular, accepted PEPs represent a standard that all static type checkers are supposed to follow. This is different from user documentation. It is also different from core language PEPs, which have direct repercussions on Python implementations (CPython, PyPy, Jython, microPython, etc.).

Perhaps the use of PEPs for static typing is more comparable to that for packaging -- there are some PEPs that describe packaging standards that all packaging tools are supposed to follow. AFAIK the packaging community never amends PEPs -- when their standard evolves they issue new PEPs.

There are also some differences -- packaging PEPs don't affect the language and its semantics at all, whereas typing PEPs sometimes affect both the language and static type checkers (i.e., separate tooling). For example, when we introduced | as a new notation for Union, some work was done in CPython to make e.g. int | str work, and some work had to be done in all static type checkers (mypy, pytype, Pyre, pyright, etc.).

All in all I think the static type checking community would be served by a more precise standardization process. Updating PEPs post-acceptance shouldn't be part of the process, so that type checker implementations aren't caught by surprise by changes to an existing PEPs. In particular, PEP 484 is what it is -- new features should be described in new PEPs. I don't think adding a "Version History" to PEPs is the way to go.

Regarding scope restrictions for type aliases, a long-standing approach in the language standardization world is for implementations to accept "extensions" of the standard, as long as they don't conflict with the standard, or as long as they are explicitly selected using some flag (either in-source or out of band). I believe that in the case of type aliases, some type checkers can choose allow type aliases in class and function scope. Code depending on such an extension will not be rejected by Python implementation. Other type checkers may flag such type aliases as errors or simply fail to recognize them, resulting in errors later in the code.

Users of such extensions who are confronted with errors from other type checkers can then choose between a number of options: rewrite their code to be fully standard-compliant (moving aliases to the global scope), add # type: ignore comments to selected lines to silence type checkers that don't allow the extension, avoid using such type checkers (this might be considered lock-in for a specific type checker, but other type checkers can simply follow suit and also allow that extension), or petition their favorite type checker to also implement the extension.

If an extension proves to be sufficiently popular, we can start a standardization campaign whose end product is a new PEP. And not all PEPs have to be major efforts -- all it takes is someone to write a draft, solicit some conversation, and submit it to the SC. (I would say that PEP 646 is atypical in its complexity and the time it has taken to get it finalized.)

[pfmoore]

Perhaps the use of PEPs for static typing is more comparable to that for packaging -- there are some PEPs that describe packaging standards that all packaging tools are supposed to follow. AFAIK the packaging community never amends PEPs -- when their standard evolves they issue new PEPs.

In principle, the latest specifications are documented in the packaging user guide. New specs, and changes to existing specs, require a PEP but the canonical document is located in the PUG. (This is the principle, in practice some older standards are still documented in their PEPs because no-one has done the work to move them yet).

A similar approach seems reasonable to me for typing (speaking as an outsider). In addition to being somewhere for the standards to live, a "typing user guide" would serve as a central location for tool-agnostic user documentation about typing. It's pretty frustrating as a non-expert user to have to trawl through the list of PEPs to look for usage information.

[encukou]

+1. Spec documents contain the status quo; PEPs contain changes to the specs plus motivation, rejected ideas, and open questions.

I converted one of the older packaging PEPs to a document, and while it did feel like a lot of work for a simple change, I like the result. Making future changes will be easier, and understanding the current state won't require following all the history.

[gvanrossum]

The only reasonable conclusion is to give up on this PEP and have a discussion in the https://github.com/python/typing tracker about this (label as "topic: feature").