Reasons for not allowing generics in ClassVar?

[treykeown]

I've read PEP 526 and searched around, but can't find any mention of why generics are not allowed in a ClassVar (just that they're not allowed). I was hoping to write a class like this:

@dataclass
class Foo(Generic[T]):
    Type: ClassVar[T]

EDIT: I think I may have a misunderstanding of how to do what I want. I want to make a subclass like this: class Bar(Foo[int]): ... and use Bar.Type as a type annotation later on. Looks like this may not be possible?

[erictraut]

I can't think of any technical reason why this isn't allowed.

Perhaps it's because class variable accesses typically don't include explicit class specialization. Using your example above, Foo[int].Type would be less typical than Foo.Type. The latter would evaluate to T or Any, depending on whether the type checker replaces the unsolved TypeVar with its default value.

FWIW, pyright emits an error if you attempt to use a type variable within a ClassVar definition (consistent with the text in PEP 526), but it otherwise works as you would expect. Mypy emits errors for both the definition and the subsequent use of the ClassVar field.

[caniko]

I forget that this limitation exists because it makes no sense WRT my mind-abstraction of Generics. I think it is the 2nd time I end up hitting this wall in two entirely separate projects 😆

Please provide solid reasoning or add the feature.

[matthax]

I'd like to throw my hat into the ring here, I'm not sure why this limitation exists, it seems inconsistent with the purpose of typings. Take for example this case where some abstract View class requires an input and return class to be declared by the implementors

class View(ABC, Generic[Message, Result]):
    # Limitation of the pep https://peps.python.org/pep-0526/#class-and-instance-variable-annotations
    # see https://github.com/python/mypy/issues/5144#issuecomment-1001222212
    # and https://github.com/python/typing/discussions/1424
    accepts: ClassVar[Message]  # type: ignore[misc]
    returns: ClassVar[Result]  # type: ignore[misc]

The expected utilization might be something like

class MyResult:
    def __init__(self, result: list[dict]):
        self.result = result


class MyView(View):
    returns = MyResult
    def serialize(self, result: list[dict]) -> MyResult:
        return MyView.returns(result)

I understand that if accepts or returns is not initialized, things will break, was this the original intention behind the limitation? If not, what was?

What steps would we need to take to have this limitation removed? It seems like a library such as mypy or pylint could handle the warning(s) related to uninitialized class variables but I don't think they're able to move forward until the restriction here is removed.

[JelleZijlstra]

I believe the technical reason why this was not allowed is that different generic instantiations of the same class share a single runtime class object, which only has space for a single ClassVar of one type. You'd get type checker behavior like this:

class Foo[T]:
    x: ClassVar[T]

assert_type(Foo[int].x, int)
assert_type(Foo[str].x, str)

But Foo[int].x and Foo[str].x refer to the same runtime object, which can't be both an int and a str.

The practical use cases people come up with tend to involve generic base classes with non-generic child classes. That does make sense at runtime and in the type system, so it would be useful to allow.

[Daverball]

If we wanted to give up slightly less safety we could also think about only allowing this pattern in abstract classes, this is still not completely safe, since accessing the attribute on the abstract base class would still be almost certainly incorrect and it is legal to access attributes on an abstract class, but it is more esoteric than the likely way this will actually be used (i.e. as a faux read-only property shared by all instances)

Since this is still a fairly strict error regardless, it could be one of the optional checks enabled through --strict.