Should `__static_attributes__` be set on dataclasses?

[ariebovenberg]

Bug report

Bug description:

I'm aware that __static_attributes__ is only intented to be a heuristic (#123860),
but perhaps dataclasses are common enough to warrant inclusion?

@dataclass
class A:
    x: int


# non-dataclass equivalent
class B:
    x: int

    def __init__(self, x):
        self.x = x


print(A.__static_attributes__)  # (), but expected ('x', )
print(B.__static_attributes__)  # ('x',)

CPython versions tested on:

3.13, 3.14

Operating systems tested on:

macOS

[ZeroIntensity]

This would require some nasty special-casing in the interpreter. __static_attributes__ is somewhat hardcoded into Python classes at build time:

cpython/Python/codegen.c

Lines 1575 to 1576 in e6c3039

	RETURN_IF_ERROR_IN_SCOPE(
	c, codegen_nameop(c, NO_LOCATION, &_Py_ID(__static_attributes__), Store));

We don't know until runtime whether or not something is a dataclass (via the @dataclass decorator), so we'd need to add a way for Python to modify that tuple after it has already been created, which is evil. What's the use case here?

[ariebovenberg]

My use case is that I'm using __static_attributes__ to detect unused __slots__ entries. I'm fine with working around this.

My secondary reason for opening this ticket was to check whether this would be easy or worthwhile to fix, since __static_attributes__ will be used for further optimizations. Everybody would like their dataclasses optimized, I can imagine.

Your answer clearly indicates it wouldn't be easy. Unless there's some indication that it'd be super beneficial (I'm not aware of the exact optimizations planned using __static_attributes__ in 3.14 and beyond), it'd be fine to close this issue

[ZeroIntensity]

Ok, yeah, if you can work around this, then that's great. Maybe someday, when we actually have some optimizations involving __static_attributes__, we'll get it working for dataclasses, but not today :)