Be stricter about access to generic vars from class

[hauntsaninja]

This behaviour was intentionally chosen in #6418

I agree with Ivan's comment there that it's similar to how mypy allows instantiation of type[Abstract] -- but that's a thing that I want to explore disallowing.

Let's see primer!

[hauntsaninja]

prefect is self type, altair is self type (singleton), artigraph is runtime typing i'm fine with, pytest is abstract generic class with only concrete subclasses, pandera is also fine, steam is self type, homeassistant is self type

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

artigraph (https://github.com/artigraph/artigraph)
+ src/arti/internal/mappings.py:246: error: Access to generic class variables is ambiguous  [misc]
+ src/arti/storage/__init__.py:90: error: Access to generic class variables is ambiguous  [misc]
+ src/arti/storage/__init__.py:105: error: Access to generic class variables is ambiguous  [misc]
+ src/arti/storage/__init__.py:115: error: Access to generic class variables is ambiguous  [misc]

pytest (https://github.com/pytest-dev/pytest)
+ src/_pytest/capture.py:913: error: Access to generic instance variables via class is ambiguous  [misc]
+ src/_pytest/capture.py:914: error: Access to generic instance variables via class is ambiguous  [misc]
+ src/_pytest/capture.py:946: error: Access to generic instance variables via class is ambiguous  [misc]
+ src/_pytest/capture.py:947: error: Access to generic instance variables via class is ambiguous  [misc]

steam.py (https://github.com/Gobot1234/steam.py)
- steam/state.py:3026: error: Access to generic instance variables via class is ambiguous  [misc]
- steam/state.py:3033: error: Access to generic instance variables via class is ambiguous  [misc]
- steam/state.py:3035: error: Access to generic instance variables via class is ambiguous  [misc]
+ steam/ext/commands/converters.py:239: error: Access to generic instance variables via class is ambiguous  [misc]

pandera (https://github.com/pandera-dev/pandera)
+ pandera/api/dataframe/model.py:262: error: Access to generic instance variables via class is ambiguous  [misc]
- pandera/api/dataframe/model.py:264: error: Unused "type: ignore" comment  [unused-ignore]
- pandera/api/dataframe/model.py:265: error: Unused "type: ignore" comment  [unused-ignore]

core (https://github.com/home-assistant/core)
+ homeassistant/components/yeelight/scanner.py:54: error: Incompatible types in assignment (expression has type "YeelightScanner", variable has type "Self | None")  [assignment]
+ homeassistant/components/yeelight/scanner.py:55: error: Incompatible return value type (got "Self | None", expected "YeelightScanner")  [return-value]

[cdce8p]

While debugging the Home Assistant error, I noticed that Self without ClassVar is currently interpreted as Any within the singleton pattern thus masking the issue. Might be worth adding a test case for it to make sure it isn't Any.

from typing import ClassVar, Self

class X:
    _inst: Self | None = None

    @classmethod
    def func(cls) -> Self:
        reveal_type(cls._inst)  # Any | None
        if cls._inst is None:
            cls._inst = cls()
        reveal_type(cls._inst)  # Any
        return cls._inst

class Y:
    _inst: ClassVar[Self | None] = None

    @classmethod
    def func(cls) -> Self:
        reveal_type(cls._inst)  # Self | None
        if cls._inst is None:
            cls._inst = cls()
        reveal_type(cls._inst)  # Self
        return cls._inst

Edit: Fix for Home Assistant: home-assistant/core#134135