support type of `self` on instance methods and type of `cls` on classmethods

[carljm]

Proper support here overlaps with generics (since Self operates like a bound typevar).

[MatthewMckee4]

Should this need a new Type::TypingSelf or similarly named type?

And should KnownInstanceType::TypingSelf contain a type, like ClassLiteralType?

[carljm]

Probably worth taking a careful look at the relevant section of the spec if you're considering working on this.

Should this need a new Type::TypingSelf or similarly named type?

I don't think a new Type variant should be necessary here, because Self is specified to work the same as a typevar with an upper bound of the enclosing class type. In other words, these two are equivalent:

class C1:
    def method(self: Self) -> Self: ...

class C2:
    def method[T: "C2"](self: T) -> T: ...

So I think that when we see an annotation of Self, we should be able to just construct the appropriate Type::TypeVar type (and add a generic context to turn the function into a generic function), without needing a new dedicated type.

And should KnownInstanceType::TypingSelf contain a type, like ClassLiteralType?

No. KnownInstanceType::TypingSelf represents the object that you get at runtime when you do from typing import Self. It is the same everywhere that typing.Self is imported. It can't carry any knowledge of any particular location where Self is used in an annotation. Its only purpose is so that we can distinguish real usage of typing.Self from some random user class that happens to be named Self. In other words, the only special behavior KnownInstanceType::TypingSelf should have is its implementation of in_type_expression.

[Glyphack]

I had a chat with Matthew and I'm working on this one.

[sharkdp]

Reopening this, as we now understand typing.Self, but not yet type of self

[MichaReiser]

@AlexWaygood was it intentional that you closed this issue?

[AlexWaygood]

no, not at all -- all I did was sync my Ruff fork with the upstream repo