Question/feature request

[NeilGirdhar]

Is it possible to make the following code produce a narrower type?

from typing import TypeVar, Generic, Any

class X:
    pass

T = TypeVar('T', bound=X)

class C(Generic[T]):
    def __init__(self, t: T):
        self.t = t

    def f(self) -> T:
        return self.t

def g(c: C[Any]) -> None:
    reveal_type(c.f())   # Any

It makes sense that the revealed type is Any and not X since c has type C[Any] and not C[X]. Is there some placeholder I can put in that means use the top level type? Like C[TopLevel]? This would ideally make the revealed type X? In this case, typing X is no problem, but sometimes the type annotations are quite long.

[erictraut]

Transferring to discussion.

[erictraut]

Since the type of c is C[Any], the type parameter T@C has effectively been replaced with type Any. That means the type of c.f is () -> Any. The Python typing rules are that Any is not narrowed under normal circumstances. There are only a few exceptions that type checker authors have agreed to: the isinstance/issubclass type guard, a class pattern in a match statement (which is the equivalent of an isinstance type guard) and a user-defined TypeGuard (a'la PEP 647).

So your options are:

1. Avoid using Any in your code.
2. Use an explicit cast.
3. Use one of the above mechanisms that allow for the narrowing of Any.

You could also define g as a generic function:

def g(c: C[T]) -> None:
    reveal_type(c.f()) # T@g

If you use the value of c.f() in this case, a type checker will validate that its use is compatible with X (which is the upper bound of T). For example, if X has a method foo, the expression c.f().foo() would be allowed.

[NeilGirdhar]

I understand that. I'm suggesting a new typing keyword that is automatically substituted for the top level type of a corresponding type variable. Thus C[TopLevel] would be equivalent to C[X] since X is the top level type of the corresponding type variable T.

Consider the test here: https://github.com/NeilGirdhar/efax/blob/main/tests/test_flatten.py, and the corresponding definition of DistributionInfo here https://github.com/NeilGirdhar/efax/blob/main/tests/distribution_info.py. The test loses all typing information because I used DistributionInfo[Any, Any, Any]. So if I want typing information, I have to use:

def test_flatten(generator: Generator,
                 distribution_info: DistributionInfo[NaturalParametrization[ExpectationParmetrization, JaxComplexArray],
                                                     ExpectationParametrization[NaturalParmetrization],
                                                     NumpyComplexArray]) -> None:

I would much rather just do

def test_flatten(generator: Generator,
                 distribution_info: DistributionInfo[TopLevel, TopLevel, TopLevel]) -> None:

It's not just shorter, but it reduces churn if the type definitions change. Note that TopLevel is recursive (it chooses the top level of the nested types too).

[erictraut]

Nothing like that exists in the Python type system. I'm not familiar with anything like that in any static type system, and I think it's unlikely such a thing would be agreed upon by the typing community.

[NeilGirdhar]

Okay, I'll propose it anyway just in case it's useful to other people. Does my example seem reasonable to you?

[erictraut]

I don't think your example makes sense for invariant type variables unless your intent is to allow callers to specify only the upper bound type and no other type arguments.

For covariant type variables, your example kind of makes sense, but the proposed TopLevel mechanism seems unnecessary then. It serves no purpose other than to save a few keystrokes.