Pep 613 / Pep 484 - specify scope restrictions and inference rules for type alias vs variables by nipunn1313 · Pull Request #2158 · python/peps · GitHub
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Simple variable assignments may be either type aliases or variables. PEP 613
provides a way to explicitly annotate a type alias. Otherwise, the type checker
should infer a type alias if all of the following conditions apply.
- There is no type annotation provided
- The LHS is a simple identifier symbol
- There is only one assignment to the LHS symbol
- The expression on the RHS of the assignment does not contain any syntactic form that would be considered illegal for a type annotation (call expressions, lambdas, comprehensions, etc.)
- The type evaluation of the RHS evaluates to an instantiable type or a union of instantiable types
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@@ -92,34 +92,38 @@ and ``InvalidType`` are not valid types. When the value expression is no longer
evaluated as a global value, unactionable type errors on all usages of ``MyType``
across the codebase can be suppressed.
Scope Restrictions:
*******************
Scoping:
********
Implicit and explicit type aliases can be made at any scope as long as they obey
the Type Alias vs Variable inference rules specified in PEP 484
::
x = ClassName
def foo() -> None:
x = ClassName
class Foo:
pass
The outer ``x`` is a valid type alias, but type checkers must error if the
inner ``x`` is ever used as a type because type aliases cannot be defined
inside a nested scope.
This is confusing because the alias declaration rule is not explicit, and because
a type error will not be thrown on the location of the inner type alias declaration
but rather on every one of its subsequent use cases.
F1 = Foo
class Bar:
F2 = Foo
F3: TypeAlias = Foo
On explicit type aliases made on assignments that break the inference rules specified
in PEP 484, type checkers should raise a clear error, communicating to the author
why the TypeAlias is invalid.
::
x: TypeAlias = ClassName
def foo() -> None:
x = ClassName
def bar() -> None:
x: TypeAlias = ClassName
class Foo:
pass
F1: TypeAlias = [f for f in Foo] # RHS not a valid type
F2: TypeAlias = Foo # Multiple assignments to F2
F2 = None
With explicit aliases, the outer assignment is still a valid type variable,
and the inner assignment can either be a valid local variable or a clear error,
communicating to the author that type aliases cannot be defined inside a nested
scope.
class Bar:
def __init__(self):
self.F2: TypeAlias = Foo # LHS not a simple identifier
Specification
Expand Down
Expand Up
@@ -200,6 +204,14 @@ appealing because it still sticks with the ``MyType = int`` assignment
syntax, and adds some information for the type checker purely as an annotation.
Version History
===============
* 2021-11-16
* Allow TypeAlias inside class/function scope
Copyright
=========
Expand Down
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pep 613 / Pep 484 - specify scope restrictions and inference rules for type alias vs variables #2158
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
Pep 613 / Pep 484 - specify scope restrictions and inference rules for type alias vs variables #2158
Filter by extension
Viewed files
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing