mypy gets confused by dataclasses with partial type hints

[wadetregaskis-linkedin]

This code:

from dataclasses import dataclass

@dataclass
class MypyBug:
    foo: str
    troz = 5

MypyBug(foo='abc', troz=11)

…yields the error message:

test.py:8: error: Unexpected keyword argument "troz" for "MypyBug"

That's simply wrong. troz is an argument to the autogenerated __init__. The code executes perfectly at runtime.

If you remove all type hints from MypyBug, mypy stops complaining. If you add type hints for all members of MypyBug, it also stops complaining.

[wadetregaskis-linkedin]

This is with mypy 0.730. I believe this didn't happen in prior versions, but I haven't double-checked.

[ilevkivskyi]

>>> MypyBug(foo='abc', troz=11)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got an unexpected keyword argument 'troz'

[wadetregaskis-linkedin]

Interesting. This is true in this degenerate example, but the real code that I derived this from does not exhibit that problem. Presumably this is because it's also utilising the declarative_base() metaclass from SQLAlchemy (which doesn't provide an __init__ either, yet seemingly causes the one created by dataclass to see untyped fields).

So I'm not sure how mypy should handle this… it's an error in the sense that mypy is making a false statement vs what the code actually does at runtime, but it is a non-trivial situation since indeed normally untyped fields aren't visible to dataclasses, per PEP 557.

[wadetregaskis-linkedin]

I guess that's not true re. __init__ from SQLAlchemy's base class - apparently it does provide a default one. If init=False is used with dataclass(), mypy doesn't do any type checking for the whole class. If it's left to True, it seems like mypy believes it exists - and behaves as if it does - even though SQLAlchemy's built-in __init__ actually overrides at runtime (as evidenced by the fact that you can successfully set untyped columns that mypy believes doesn't exist).

[wadetregaskis-linkedin]

Maybe what mypy could do better in this situation is explicitly point out that there is an attribute declared on the class (that matches the name of the init argument being used) but that it's not being treated as a dataclass field because it lacks the type hint.

Turns out this confusion re. this type hint requirement was erroneously allowing some unit tests to pass (because the autogenerated __eq__ was also missing most of the fields and thus returning false positives), even though in actual production use everything happened to work correctly.

[ilevkivskyi]

Maybe what mypy could do better in this situation is explicitly point out that there is an attribute declared on the class (that matches the name of the init argument being used) but that it's not being treated as a dataclass field because it lacks the type hint.

This may be not trivial actually, because this would require defining an additional hook in our dataclasses plugin. If you are willing to make a PR that would add such a note in case of an extra argument, then it is OK, otherwise I wouldn't bother.