generic is incorrectly inferred as invariant if class uses Self type on an attribute

from typing import Self


class Foo[T]:
    instance: Self # commenting out this line makes the error go away

    def foo(self) -> T: ... # type:ignore[empty-body]


class Bar(Foo[int]): ...

# Incompatible types in assignment (expression has type "Bar", variable has type "Foo[object]")  [assignment]
foo: Foo[object] = Bar()

playground

class Foo[T]:
    instance: Self

is invariant for the same reason

class Foo[T]:
    instance: Foo[T]

is invariant: instsance is a settable attribute. So this is actually true positive.

hmm interesting. here's a simplified example that mypy doesn't catch:

from typing import Self, reveal_type

class Foo:
    instance: Self

class Bar(Foo): ...

bar = Bar()

def fn(value: Foo):
    foo: Foo = value
    foo.instance = Foo()

fn(bar)

reveal_type(bar.instance) # Bar, but Foo at runtime

playground

This is a well known unsafety of self-types. In fact, essentially same problem existed long before Self notation was even introduced, for example this is unsafe:

from typing import TypeVar

T = TypeVar("T")
class Base:
    def foo(self: T, arg: T) -> None: ...

class Sub(Base):
    x: int
    def foo(self, arg: Sub) -> None:
        arg.x

b: Base = Sub()
b.foo(Base())

Most (if not all) false negatives with self types boil down to this hole in type system. However, the current consensus is that it is impossible to fix it without making self-types a pain to work with.

my proposed solution is to add new rules to:

ban Self from being used in a contravariant position (except for the self parameter on instance methods) (Self should not be allowed in a contravariant position DetachHead/basedpyright#1586)
ban calling instance methods on the class (ban calling instance methods on classes DetachHead/basedpyright#1566)

i've found that there is no downside to adding new diagnostic rules for stuff like this, because users who want the additional safety can benefit from them, but users who think it would make self-types a pain to work with can just keep those rules disabled.

Yeah, adding a new flag (or if possible an error code) may be a solution. This still however requires some discussions on exact semantics. Also to give correct expectations: since this hole causes (surprisingly) few problems in real-world code, fixing this is not high priority.

If you are interested in this, I guess #15619 may be a better place to continue discussion.

from typing import TypeVar

class Base:
    def foo(self) -> None: ...

class Sub(Base):
    x: int = 1
    def foo(self) -> None:
        self.x

b: type[Base] = Sub
b.foo(Base())

class Foo[T]:
instance: Self
is invariant for the same reason

class Foo[T]:
instance: Foo[T]
is invariant: instsance is a settable attribute. So this is actually true positive.

why is there no error here then?

from typing import Self, Generic, TypeVar

out_T = TypeVar("out_T", covariant=True)

class Foo(Generic[out_T]):
    instance: Self

    def f(self) -> out_T: ...
    
f1 = Foo[int]()
f2: Foo[object] = f1

what exactly does this help with? making it invariant because of Self usage doesn't prevent any invalid usages

From the typing spec:

from typing import Self

@dataclass
class LinkedList(Generic[T]):
    value: T
    next: Self | None = None

@dataclass
class OrdinalLinkedList(LinkedList[int]):
    def ordinal_value(self) -> str:
        return as_ordinal(self.value)

xs = OrdinalLinkedList(value=1, next=LinkedList[int](value=2))
# Type error: Expected OrdinalLinkedList, got LinkedList[int].

if xs.next is not None:
    xs.next = OrdinalLinkedList(value=3, next=None)  # OK
    xs.next = LinkedList[int](value=3, next=None)  # Not OK

The code above is semantically equivalent to treating each attribute containing a Self type as a property that returns that type:

from dataclasses import dataclass
from typing import Any, Generic, TypeVar

T = TypeVar("T")
Self = TypeVar("Self", bound="LinkedList")


class LinkedList(Generic[T]):
    value: T

    @property
    def next(self: Self) -> Self | None:
        return self._next

    @next.setter
    def next(self: Self, next: Self | None) -> None:
        self._next = next

class OrdinalLinkedList(LinkedList[int]):
    def ordinal_value(self) -> str:
        return str(self.value)

So the example in the OP is specified to be equivalent to:

class Foo[T]:
    @property
    def instance[SelfT: Foo[Any]](self) -> Self: ...
    @instance.setter
    def instance[SelfT: Foo[Any]](self, instance: SelfT, /) -> None: ...

    def foo(self) -> T: ... # type:ignore[empty-body]

class Bar(Foo[int]):
    @property
    def instance[SelfT: Bar[Any]](self) -> Self: ...
    @instance.setter
    def instance[SelfT: Bar[Any]](self, instance: SelfT, /) -> None: ...

Mypy seems to assume that Self is class-scoped. It isn't; Self is method- or property-scoped. So Self cannot influence the (variance of) class-scoped type parameters.

Mypy seems to assume that Self is class-scoped. It isn't; Self is method- or property-scoped. So Self cannot influence the (variance of) class-scoped type parameters.

Wouldn't this mean that ClassVar[Self] is illegal? This is actually part of the test-suite. Your comment also gave me the idea to try the following, since mypy sometimes treat an annotation inside __init__ differently than an annotation inside the class-body.¹ This led to an odd result playground

from typing import Self

class Foo:
    def __init__(self) -> None:
        self.instance: Self = self
# main.py:5: error: Incompatible types in assignment (expression has type "Foo", variable has type "Self")  [assignment]

as an annotated attribute inside the class body can be a class- or instance-attribute whereas a self.attr annotated inside __init__ is always treated as an instance-only attribute. Though I sometimes wish that were the default for everything that's not explicitly marked as ClassVar. ↩

Wouldn't this mean that ClassVar[Self] is illegal?

Although not explicitly stated in the typing spec, it would be legal if you think of class-attributes as a "classproperty", i.e. a @property + @classmethod, analogous to instance attributes -> @property

Navigation Menu

Repository navigation

generic is incorrectly inferred as invariant if class uses `Self` type on an attribute #18334

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

generic is incorrectly inferred as invariant if class uses Self type on an attribute #18334

Description

Activity

ilevkivskyi commented on Oct 15, 2025

DetachHead commented on Oct 16, 2025

ilevkivskyi commented on Oct 16, 2025

DetachHead commented on Oct 16, 2025

ilevkivskyi commented on Oct 16, 2025

KotlinIsland commented on Oct 16, 2025

KotlinIsland commented on Oct 16, 2025

jorenham commented on Oct 17, 2025

randolf-scholz commented on Oct 27, 2025

Footnotes

jorenham commented on Oct 27, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions

generic is incorrectly inferred as invariant if class uses `Self` type on an attribute #18334