Does typing.Self not work on class variables?

[McDic]

Consider following Python 3.11 code;

import math
import typing


class Team:
    """
    Represent "team" in Minecraft.
    """

    _cache: dict[str, typing.Self] = {}

    def __init__(self, name: str):
        self._name = name
        if self._name in type(self)._cache:
            raise ValueError('Team "%s" already exists;' % (self._name,))
        else:
            type(self)._cache[self._name] = self

    @property
    def name(self):
        return self._name

    @classmethod
    def get_team(cls, name: str) -> typing.Self:
        """
        Use this method to create a team instead of calling constructor directly.
        """
        if name in cls._cache:
            return cls._cache[name]
        else:
            return cls(name)

Then running mypy 1.1.6 will yield following error on return cls._cache[name];

Incompatible return value type (got "Team", expected "Self")

Does typing.Self apply only when it is associated with member function parameter or return type, not for variables defined in a class body? I wanted to ask in mypy repository but it seems there is no discussion, and both repositories are maintained under same organizations so I uploaded my question here.

[Gobot1234]

That looks like a mypy bug. This should work, atleast in my head.

[erictraut]

It type checks without error in pyright.

[Daverball]

I think I get a related error in mypy in types-WTForms with subclassing where Field.widget is both a class and a instance variable so it's annotated as _Widget[Self], if you want to carry that forward in a subclass that defines its own default widget you need to ignore a type error when setting the default widget with the _Widget[Self] annotation, so you don't restrict subclasses. Also note that the type var in this case is contravariant, so substituting a more general widget is always allowed.

It looks to me like Self immediately gets substituted with the class in a class context by mypy, rather than binding Self to it and still treating it like Self depending on the context.

[juk-r]

I think this should not work. Consider example:

import typing

class Sup:
    def __init__(self):
        self.self: typing.Self = self

class Sub(Sup):
    ...

def set_self(x: Sup):
    x.self = Sup()
    
sub = Sub()
set_self(sub)
reveal_type(sub.self)

Revealed type is "Sub", but runtime type is "Sup".

[Daverball]

It's indeed not type safe for writable attributes, but we generally have too loose of a type restriction on attributes. technically all read-write attributes should be invariant, i.e. subclasses would not be allowed to change the type, so this is not an issue limited to typing.Self, but currently we're allowed to overwrite an attribute in a subclass with a more specific type:

class Foo:
    x: object

class Bar(Foo):
    x: int

def set_x(obj: Foo, value: object) -> None:
    obj.x = value

bar = Bar()
set_x(bar, object())
reveal_type(bar.x)

So this example has the exact same problem as yours without using typing.Self.

For read only attributes it would be type-safe, since those are covariant.

So I don't think this is a valid argument against typing.Self working in a class context.

[juk-r]

Your example works with mypy, but not with pyright which reports reportIncompatibleVariableOverride. (view)

[Daverball]

pyright is a little bit ahead on that front right now, yes. But things like that still need to be properly formalized, so that type checkers have a common spec to work off from.