Repository navigation
Return type of class decorator is ignored #16241
Description
MyPy seems to ignore the return type of class decorators. @AlexWaygood 's suggested I create a minimal repro of this problem:
from typing import Any
class T:
y: int
def some_decorator(cls: type[Any]) -> type[T]:
cls.y = 1
return cls
@some_decorator
class X:
a: int
def f(x: X) -> None:
print(x.y) # No attribute!This makes it impossible to define a dataclass transform that produces ordinary dataclasses:
import dataclasses
from dataclasses import replace
from typing import Any, ClassVar, Protocol, dataclass_transform
class DataclassInstance(Protocol):
__dataclass_fields__: ClassVar[dict[str, dataclasses.Field[Any]]]
@dataclass_transform()
def dataclass(cls: type[Any]) -> type[DataclassInstance]:
return dataclasses.dataclass(cls)
@dataclass
class X:
a: int
def f(x: X) -> X:
return replace(x, a=1) # Error: dataclass expected
Activity
JelleZijlstra commentedon Oct 9, 2023
Duplicate of #3135?
NeilGirdhar commentedon Oct 9, 2023
@JelleZijlstra Not exactly. If I write it the other way
X = some_decorator(X), then I get:NeilGirdhar commentedon Oct 9, 2023
I can see that the decorator is rightly skipping these checks, but the decorator's return type seems to be ignored. I think it should be assigned to the name it decorates (in this case,
X).In an ideal world, I would be able to annotate the decorator:
erictraut commentedon Oct 9, 2023
This is covered by #11117.
JelleZijlstra commentedon Oct 9, 2023
Those errors look correct. After you define a class, mypy won't let you reassign its name.
That's #3135, right? In any case I don't think mypy is misinterpreting your code. If you annotate your decorator with
@dataclass_transform, you assert that it returns the same class with dataclass-like semantics. The return type annotation doesn't matter there.If your request is that mypy infers an intersection type in this particular case, that seems out of scope until intersections are actually part of the type system.
NeilGirdhar commentedon Oct 9, 2023
Yeah, both of these checks do make sense. No argument there.
Yes, sorry I didn't see this comment, which covers my case.
It depends on what you mean by "dataclass-like semantics". My problem is that
@dataclass_transformdoes not (and should not) assert that it returns the same class, but inheriting fromDataclassLike—that is, a so-decorated class won't be passable tofieldsandreplace. I initially thought so too, but this comment explained it.Yes, I know. I'm just pointing that out so that we don't debate about the lost type information (
type[T]) from applying the decorator.Yes, exactly right, thanks.
In any case, I guess we can close this as a duplicate of #3135. Seems to me that fixing that should fix the two examples I gave above?