Mypy treating type of final class variable in dataclass as Any

[ipilcher]

Bug Report

from dataclasses import dataclass
from typing import ClassVar, Final, reveal_type

class Bar: pass

@dataclass
class Foo:
    cv: ClassVar[Final[dict[type[Bar], Foo]]] = {}

reveal_type(Foo.cv)

$ mypy test.py
test.py:10: note: Revealed type is "Any"
Success: no issues found in 1 source file

The correct type of Foo.cv is builtins.dict[type[Bar], Foo].

To Reproduce

https://mypy-play.net/?mypy=latest&python=3.14&gist=2fad4ef5fded90ecaeb0f1d1e59d882a

Expected Behavior

reveal_type should report the correct type for the class variable.

Actual Behavior

reveal_type showed incorrect type (Any).

Your Environment

• Fedora 44
• python3-mypy-1.18.2-4.fc44.noarch (reproducible with Mypy 2.3.1)
• python3-3.14.6-1.fc44.x86_64
• No config files used

[A5rocks]

This is because mypy is erroring about line 8, i.e. the definition of cv. Since it doesn't know what to say the type of cv is (since there was an error), we consider it Any. This sounds reasonable to me.

[ipilcher]

This is because mypy is erroring about line 8, i.e. the definition of cv. Since it doesn't know what to say the type of cv is (since there was an error), we consider it Any. This sounds reasonable to me.

What error? I don't see any error when I run Mypy locally or at the mypy-play.net that I provided.

[A5rocks]

Huh, my bad. I tested on Python 3.12 but it seems on Python 3.13 and 3.14 we somehow don't error about cv. I think that in particular is the bug, though I'll reopen this for now.

[CAOShurong]

I can reproduce this and I think I've pinned the mechanism. Posting it here since it looks like a genuine regression (not just a typo in the report), matching @A5rocks's hunch that 3.13/3.14 behave differently.

Reproduction (verified locally)

from dataclasses import dataclass
from typing import ClassVar, Final, reveal_type

class Bar: pass

@dataclass
class Foo:
    cv: ClassVar[Final[dict[type[Bar], Foo]]] = {}

reveal_type(Foo.cv)

Interpreter	Result
CPython 3.11 / 3.12	error: Final can be only used as an outermost qualifier in a variable annotation [valid-type] (so the Any is expected — it's a consequence of the error)
CPython 3.14	reveal_type reports Any, no error

So on 3.13+ the annotation is accepted (no valid-type), but the variable's type still collapses to Any. That's the bug: silently wrong type instead of either an error or the correct type dict[type[Bar], Foo].

Why it's version-gated

In mypy/typeanal.py, the ClassVar[...] branch analyzes its single type argument with:

return self.anal_type(t.args[0], allow_final=self.options.python_version >= (3, 13))

Nested Final[...] inside ClassVar[...] only became accepted when allow_final=True, which is gated on python_version >= (3, 13). On 3.11/3.12 the same inner Final hit the not self.allow_final path and raised valid-type (see the FINAL_TYPE_NAMES branch in try_analyze_special_unbound_type), so the Any was at least explained by an error. On 3.13/3.14 the error is suppressed but the type is still resolved to AnyType(TypeOfAny.from_error) rather than to the inner type — hence the silent collapse.

Sanity check (the surrounding machinery is fine)

These reveal the correct type and don't error on 3.14:

cv: Final[ClassVar[dict[type[Bar], Foo]]] = {}   # -> dict[type[Bar], Foo]
cv: ClassVar[dict[type[Bar], Foo]] = {}           # -> dict[type[Bar], Foo]

Only the ClassVar[Final[...]] ordering collapses.

Suggested fix direction

In try_analyze_special_unbound_type's FINAL_TYPE_NAMES branch, when self.allow_final is set (i.e. a nested Final is legitimately accepted in this context, e.g. inside ClassVar[Final[...]]), don't return AnyType(TypeOfAny.from_error) — analyze and return the inner type instead:

elif fullname in FINAL_TYPE_NAMES:
    if self.prohibit_special_class_field_types:
        self.fail(...)
    elif not self.allow_final:
        self.fail("Final can be only used as an outermost qualifier ...")
    elif t.args:
        # Nested Final[...] is accepted here (e.g. ClassVar[Final[...]] on 3.13+);
        # preserve the inner type instead of collapsing to Any.
        return self.anal_type(t.args[0])
    return AnyType(TypeOfAny.from_error)

(I prototyped this locally against the 3.14 build and reveal_type(Foo.cv) then reports dict[type[Bar], Foo]; the Final[ClassVar[...]] and plain ClassVar[...] cases are unaffected.) A maintainer may prefer to instead keep the existing error behavior for the nested form on all versions — but the current "accepted-but-Any" state is clearly wrong either way.

Happy to turn this into a PR with a regression test if you'd like; I haven't opened one since I'm not sure which fix direction the maintainers prefer. (Assistance: this analysis was produced with AI tooling.)

[ipilcher]

Huh, my bad. I tested on Python 3.12 but it seems on Python 3.13 and 3.14 we somehow don't error about cv. I think that in particular is the bug, though I'll reopen this for now.

Yeah. The code relies on PEP 694/794, which is only in Python 3.14+, so it makes sense that it produces an error on earlier versions.

[ipilcher]

So on 3.13+ the annotation is accepted (no valid-type), but the variable's type still collapses to Any. That's the bug: silently wrong type instead of either an error or the correct type dict[type[Bar], Foo].

Makes sense. The combination of ClassVar and Final was added in Python 3.13 (IIRC) specifically for dataclasses, where ClassVar is the only way to define a class variable.