Qualified alias names are mishandled

[pkch]

T = TypeVar('T')

class X(Generic[T]):
    A = X[T]
    def f(self, x: int = 1) -> X[T]: ...
    a: X[T]
    b: A = a # ok
    def g(self) -> None:
        a: X[T]
        b: X.A = a # ok


def g(x: X[T]) -> None:
    p: X[T] = x.f() # ok
    q: X.A = x.f() # fail

I think it should pass, unless qualified aliases are not allowed (in which case it should fail in X.g()). In addition, the error is confusing: Incompatible types in assignment (expression has type m.X[T], variable has type m.X[T]).

[gvanrossum]

I'm guessing that the code for aliases just isn't robust enough.

Also, running this code gets

    A = X[T]
NameError: name 'X' is not defined

and attempting to fix that using string quotes elicits other errors. But I'm guessing you've boiled this down from a more complicated real use case.

Finally even if all that was taken care of, A would still mean X[Any] because a generic alias requires using [<something>] to fix the type parameter, and without that defaults to [Any].

@ilevkivskyi Thoughts?

[ilevkivskyi]

I noticed that aliases work normally only when they are global (this is explicitly visible in semananl.py, for example here also see this comment), when I was working on generic aliases. I didn't fix it at that time, I don't remember why.

Concerning the missing Any substitution: this may be because of interference with analize_member_access (most probably I didn't consider this case because I was only thinking about globally defined aliases).

I don't have an immediate idea how to fix this, but probably this should not be too difficult.

[neiljp]

I've just seen the simple case of 'only global aliases work' in porting the zulip mypy to use 0.521, where the following did not seemingly generate an error previously (reduced example):

from typing import List, Dict, Any
def func():
    # type: () -> None
    L = List[Dict[str, Any]]
    def nested(x):
    # type: (L) -> None
        pass

Strangely, at least to me, if the annotation of func is removed, then mypy succeeds, whereas with it, it currently generates: error: Invalid type "L".

[gvanrossum]

Removing the annotation on func disables all checks inside it.

[ilevkivskyi]

Currently, prohibiting type aliases at function scope is more a deliberate choice, rather than a limitation. One is still allowed to define type aliases at class scope, but only subscripted, i.e.:

class A: ...
class C:
    x = A  # this is an ordinary member with type 'Type[A]'
    y = Dict[str, T]  # this is a type alias

One can always make a variable instead of an alias by adding an explicit annotation. In #3524 I proposed to apply the same rule at a function scope, but Guido said that this would require many explicit annotations in some internal code bases, since class valued variables are used much more often than aliases at a function scope.

[ilevkivskyi]

Actually, I just re-read that discussion and it looks like the example Guido mentioned deals with class objects (like int), not types (like List[int]), so that I think that we can allow aliases at function scopes, if the alias is subscripted (i.e. exactly the same as we do at class scopes now). This will:

• simplify the rules (no subtle difference between class and function scopes)
• solve the Zulip's use case
• cause no additional errors for situations where classes are used as values (not aliases).

@gvanrossum @JukkaL what do you think?

[JukkaL]

@ilevkivskyi Agreed that aliases to subscripted types should be allowed everywhere. Only simple aliases to class objects (without subscripts) are sometimes problematic.