[Typing-sig] Re: PEP 613 and type aliases in nested scope

1 Nov 2021

      ...
My understanding is that in PEP 484, type aliases were global variables that were assigned to types.
I don't see anywhere in PEP 484 that limits type aliases to the global (module) level. Pyright currently allows type aliases to be defined in classes and functions as well. Mypy apparently does as well.

This type checks without error in both mypy and pyright:

```python
def func1(val: int) -> None:
    Alias = list[int]
    x: Alias = [val]

class Class1:
    Alias = list[int]
    def method1(self) -> Alias:
        return [2]
```

For generic type aliases defined within a nested scope, mypy does emit an error if the type variable is bound in that scope. ("Can't use bound type variable to define generic alias".) Pyright doesn't flag this an error but should. I'll file a bug to track this.

```python
T = TypeVar("T")

def func2(val: T):
    Alias = list[T]
    x: Alias = [val]

class Class2(Generic[T]):
    Alias = list[T]
    def method1(self, x: T) -> Alias:
        return [x]
```
...
I’d make the case that the typing PEP should describe a consistent typing experience for the language
I also prefer that we define the desired behavior in the PEPs and strive for consistent behavior across type checkers. That would seem to be in the best interest of the Python community.

I think there are several defensible positions to take, but let me propose the following:

* Both implied type aliases (introduced in PEP 484) and explicit type aliases (introduced in PEP 613) are allowed within module, class and function scopes.
* Type aliases that use bound type variables (those defined within a class or function scope) are forbidden and should generate an error.

This would require us to 1) revise PEP 484 for clarity, 2) revise PEP 613 to loosen the requirements. I don't think it would require any changes to mypy. It would require a small bug fix in pyright, but I plan to make that change regardless. I haven't tested the behavior of the other type checkers (pyre, pytest, PyCharm), so I'm not sure what changes would be required in those cases.

Thoughts?

--
Eric Traut
Contributor to Pyright & Pylance
Microsoft