remove type statement restrictions unsupported by spec or PEP#2249
remove type statement restrictions unsupported by spec or PEP#2249
Conversation
|
|
||
|
|
||
| def func3(): | ||
| type BadTypeAlias15 = int # E: alias not allowed in function |
There was a problem hiding this comment.
If this is allowed, should we not retain these and mark them as OK?
There was a problem hiding this comment.
That would be a more controversial change, since it would render every other type checker non-compliant. It would require adding language to the spec requiring this support.
The intent of this PR is not to require that type checkers support these cases, but to leave it up to individual type checkers (since the spec has nothing to say about it) pending a possible future effort to add clarifying language one way or another in the spec.
There was a problem hiding this comment.
(Makes sense. I don't disagree that these should be allowed, but it seems like it's decreasing "conformity", so just wondering if resolving this either way should be tracked in an issue.)
There was a problem hiding this comment.
We could, though there's an infinite universe of things not specified in the typing spec or tested in the conformance suite, and we should prioritize standardizing the things that most impact users; I don't think this is very high on that list.
rchen152
left a comment
There was a problem hiding this comment.
Huh, for some reason I thought defining a type alias in a function body wasn't allowed, but you're right, that restriction doesn't seem to appear anywhere in the spec.
The conformance suite currently mandates that a type checker must reject type statements (PEP 695 type aliases) which redefine an existing type alias, or which occur inside a function scope. These restrictions are not supported by any corresponding language in either PEP 695 or the typing spec. "Redefining" a type alias can be useful if the redefinition is conditional, and a locally-scoped type alias can express that the type alias is only relevant within a particular scope. The ty model for type aliases does not require either of these prohibitions, and it doesn't seem to serve our users to artificially implement them in order to satisfy an unsupported conformance suite assertion.
If there are good reasons that all type checkers must implement these prohibitions, we should add language to the spec requiring them.