Special dunder attributes on dataclass not treated as `__init__` args

[ktbarrett]

Bug Report

Dunder-variables on dataclasses are considered to be arguments instead of ignored, per the dataclass documentation.

To Reproduce

https://mypy-play.net/?gist=27221945829d19cc0407d970cc1cb1f8

from dataclasses import dataclass

@dataclass
class Example:
    a: int
    
    __name__: str
    
    
e = Example(1)  # error: Missing positional argument "__name__" in call to "Example"  [call-arg]

Python run time does not consider __name__ as a required arguments, but mypy does.

[A5rocks]

Actually, dunders are not excluded from the dataclass. You can see this from the repr for Example at runtime, or by trying this:

>>> @dataclass
... class Example:
...     a: int
...
...     __nam__: str
...
>>> Example(1)
Traceback (most recent call last):
  File "<python-input-7>", line 1, in <module>
    Example(1)
    ~~~~~~~^^^
TypeError: Example.__init__() missing 1 required positional argument: '__nam__'

I'm not sure why specifically __name__ is allowed at runtime...

[ktbarrett]

It's not just __name__, but __qualname__, __module__, __doc__, possibly others, but those are the ones I know about. I needed to specify them to make more pedantic type checkers happy.

EDIT: also __hash__.

[A5rocks]

Aha I think I know what's going on. We can imagine dataclasses as getting the default value by doing getattr(cls, attribute) and e.g. for __name__ that's provided by default. This isn't actually behavior dataclasses explicitly implements (and might be considered a bug!!!), but it's a thing... as a test for this, note:

>>> class Blahhhh:
...     x = 5
...
>>> @dataclass
... class Example1(Blahhhh):
...     a: int
...
>>> @dataclass
... class Example2(Blahhhh):
...     a: int
...     x: int
...
>>> inspect.signature(Example1), inspect.signature(Example2)
(<Signature (a: int) -> None>, <Signature (a: int, x: int = 5) -> None>)

Example1 shows that x isn't a recognized field (otherwise it would inherit), but Example2 shows it still sets the default.

[A5rocks]

Could you update the issue title for this increased scope :-)

(I'm unable to.)

[ktbarrett]

This isn't actually behavior dataclasses explicitly implements (and might be considered a bug!!!)

I'm not sure this is a bug, but a hack for a corner case. If you make this a field, dataclass complains.

>>> from dataclasses import dataclass, field
>>> @dataclass
... class A:
...     __qualname__: str = field(init=False, hash=False, compare=False)
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
TypeError: type __qualname__ must be a str, not Field

It also doesn't seem dataclass likes you overriding those special dunder attributes with things like propertys =/ This seems like an over-specification by dataclass and a weird special case.

[A5rocks]

I think that TypeError is from CPython actually:

>>> class X:
...     __qualname__ = 5
...
Traceback (most recent call last):
  File "<python-input-0>", line 1, in <module>
    class X:
        __qualname__ = 5
TypeError: type __qualname__ must be a str, not int

(notably it doesn't seem mypy warns about this. I made #20821 to track this, so let's not get offtrack about it here!)