Skip to content

remove type statement restrictions unsupported by spec or PEP#2249

Open
carljm wants to merge 2 commits intomainfrom
cjm/typealias
Open

remove type statement restrictions unsupported by spec or PEP#2249
carljm wants to merge 2 commits intomainfrom
cjm/typealias

Conversation

@carljm
Copy link
Copy Markdown
Member

@carljm carljm commented Apr 7, 2026

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.

@carljm carljm added the topic: conformance tests Issues with the conformance test suite label Apr 7, 2026


def func3():
type BadTypeAlias15 = int # E: alias not allowed in function
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is allowed, should we not retain these and mark them as OK?

Copy link
Copy Markdown
Member Author

@carljm carljm Apr 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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.)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

@rchen152 rchen152 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

topic: conformance tests Issues with the conformance test suite

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants