Type parameter defaults do not get bound when accessing a method

[Gobot1234]

Describe the bug
Accessing a method on a class does not bind any associated type parameters to their default value leaving types unknown. I don't think this is described in PEP 696 but I can add it if you think it should be.

Code or Screenshots

class Foo[T = int]:
    def bar(self) -> None:
        ...

Foo.bar(Foo())

VS Code extension or command-line
pylance v2023.8.40

[erictraut]

I think the PEP should make this clear.

In particular, it should specify that the expression Foo.bar above should specialize bar to Foo[int].

I'll note that pyright and mypy do not handle the evaluation of Foo.bar or Foo[str].bar in the same manner, even prior to PEP 696.

from typing import Generic, TypeVar

T = TypeVar("T")

class Foo(Generic[T]):
    def bar(self) -> None:
        ...

reveal_type(Foo.bar) # pyright: (self: Foo[Unknown]) -> None; mypy: [T] (self: Foo[T]) -> None
reveal_type(Foo[str].bar) # pyright: (self: Foo[str]) -> None; mypy: (self: Foo[T]) -> None

In other words, pyright always specializes in this case, but mypy does not. I think pyright's behavior is more defensible in this case because mypy is completely ignoring an explicit specialization.

My point is that if you specify this in PEP 696, you're going to need to clarify a behavior that was previously not specified in any PEP or official documentation, and that will likely force either pyright or mypy (or both) to change their existing behavior in a way that will not be backward compatible.

[Gobot1234]

This has opened a can of worms in regards to PEP 718 as well which I have also authored, evidently, this needs documenting clearly.

I think the ideal behaviour is this

class Foo[T=int]:
    def self(self) -> T: ...

assert_type(Foo().self(), int)
assert_type(Foo.self(Foo()), int)
Foo.self(Foo[str]())  # errors because Foo is bound to Foo[int] 

assert_type(Foo[str]().self(), str)

Foo().self[str]()  # should error because instance is already specialised (assuming PEP 718 is supported)

pyright fails cases 2, 3 and 5 (though the latter is to be expected)
Though maybe this is more of a discussion for typing-sig/the issue tracker.

[erictraut]

I'm going to close this issue for now. If and when we come to a consensus on the other thread and the other type checker maintainers also commit to making any necessary changes, then I'll consider making a change in pyright. Until then, I don't think it's worth the churn for pyright users.