Implicit class var type variables, or type variable becomes the class in which it is bound?

[qexat]

I don't even know how to explain this in a non-confusing manner.

Here is the reproduction code:

import typing

type Fn[A, B] = typing.Callable[[A], B]

class __Forall[A]:
    id: Fn[A, A] = lambda x: x

_A = typing.TypeVar("_A")
id_ = __Forall[_A].id
typing.reveal_type(id_)  # Type of "id_" is "(__Forall[_A@id_]) -> __Forall[_A@id_]"

Why is _A's solution __Forall[...]? Clearly, Pyright knows that id is not a bound method, and while it's not specifically typed as a ClassVar (in which the use of type var would raise an error), Pyright still concludes that accessing it as such is fine. Anyway, the inferred type of id_ does not seem right to me especially given that e.g. id_(3) indeed yields 3 or id_("hello") returns "hello" at runtime.

I'm not sure whether this is an actual Pyright issue, a typing spec hole, a misunderstanding of mine or something else entirely, hence I'm opening a discussion instead. Either way, I still think the current behavior is incorrect, at least in terms of accepting the definition of "implicit" ClassVars. Rejecting is, I think, more desirable than silently accepting with an incorrect inference.

Worth noting, mypy's output is the following:

main.py:9: error: Access to generic instance variables via class is ambiguous  [misc]
main.py:9: error: Type variable "__main__._A" is unbound  [valid-type]
main.py:9: note: (Hint: Use "Generic[_A]" or "Protocol[_A]" base class to bind "_A" inside a class)
main.py:9: note: (Hint: Use "_A" in function signature to bind "_A" inside a function)
main.py:10: note: Revealed type is "def (_A?) -> _A?"

[Daraan]

This might give you some information: #7089

[qexat]

Thanks! It doesn't really explain why Pyright doesn't reject the reproduction though :(

[erictraut]

Please refer to this documentation for an explanation of how pyright treats class and instance variables. In your example, the class-scoped variable id is treated as a "regular class variable" that may be accessed from the class but may also be overwritten by an instance. It is neither a "pure class variable" or a "pure instance variable".

The typing spec does not currently provide much guidance for type checkers in this regard. It's an area where additional formalization and specification is needed.