This is not a bug that I encountered in the wild, but I happened to notice the possibility for this while reading the source.

from dataclasses import dataclass@dataclass(frozen=True)class X:    BUILTINS: strX(5)

will give you:

Traceback (most recent call last):  File "<stdin>", line 1, in <module>  File "<string>", line 3, in __init__AttributeError: 'int' object has no attribute 'object'

There are other field names that you can use to trick dataclass into bad behaviour, but all of the other ones are prefixed by an underscore.

So one "fix" is pretty simple: just renameBUILTINS to_BUILTINS in dataclasses.py to bring it in line with the others.

If a single underscore doesn't feel like sufficient "this is the user's fault", we could use__dataclass_* (like we do for__dataclass_self__ param to__init__)

For what it's worth, the only thing we needBUILTINS for is so we can accessobject inside__init__, so an alternative fix could be to use().__class__.__base__ instead ofBUILTINS.object (and skip the locals dance needed to defineBUILTINS altogether)

If any of that sounds worth doing, I'd be happy to open a PR

• PR:gh-96151: Use a private name for passing builtins to dataclass #98143

• PR:[3.10] gh-96151: Use a private name for passing builtins to dataclass. This now allows for a field named BUILTIN (gh-98143) #98899

• PR:[3.11] gh-96151: Use a private name for passing builtins to dataclass. This now allows for a field named BUILTIN (gh-98143) #98900