stubgen: generate valid dataclass stubs

[hamdanal]

Fixes #12441

Edit:
Also fixes #9986
Edit 2:
Fixes #15966

[sobolevn]

Please, add test cases for:

1. InitVar annotation
2. dataclass() with other keywords, not only init=False
3. Fields defined with = field() (it is special enough to be tested)
4. _: dataclasses.KW_ONLY mark

[sobolevn]

I think that init=False is assumed here.

[hamdanal]

According to the dataclass documentation,

init: If true (the default), a __init__() method will be generated.
If the class already defines __init__(), this parameter is ignored.

So it is ignored in this case. This was not the goal of the test anyway, it was to test that user defined methods are always included in the stub.

[hamdanal]

Thanks for the review, I added more tests.

2. dataclass() with other keywords, not only init=False

Added more keywords in the tests but the goal of the test is make sure keywords are not stripped out and call expressions are recognized as dataclasses, it is not to test each keyword individually as they are all handled the same way.

3. Fields defined with = field() (it is special enough to be tested)

Thanks. Since a field() assignment could affect the signature of __init__ and since stubs don't have default values yet (I opened #15355 to preserve simple defaults in function signatures in stubs but we still don't have neither "call" defaults like field() nor attribute defaults, so the assignment to field() gets erased), it is not safe to ignore the generated __init__ method, so now I keep it.

4. _: dataclasses.KW_ONLY mark

It was indeed special because it was considered private name, added a test.

[hamdanal]

Hmm, how can I restrict a stubgen test case to a certain python version?

[hamdanal]

Sorry to ping you @sobolevn. Could you please take another look? This came up again in a new project of mine. Thank you

[hauntsaninja]

Thank you!

[thomasgilgenast]

Sorry to comment on an old, merged PR, but I wanted to ask if it's expected that the arguments to __init__() are missing type annotations in the generated stub.

If I install this stub and then try to typecheck

X(a="foo", ...)

I would expect mypy to error with

error: Argument "a" to "X" has incompatible type "str"; expected "int"  [arg-type]

but instead it passes (I think the type annotation for a is implicitly Any when it's not annotated in the signature, which is incorrect I think - I think the type of a should be int, not Any).

Let me know if this is actually better positioned as a new issue (with reproducible example etc.), but I just wanted to see if I was missing something obvious before opening a new one.

[hamdanal]

Stubgen doesn't use inferred types of parameters in generated stubs unless it sees a parameter with a primitive default value. You'll always need to tweak the generated stubs by hand if you want better experience with the type checker.

Also note that the __init__ method can be safely deleted from the stub most of the time. It is included because a field declaration like some_field: int = field(init=False) that affects the signature of __init__ cannot be currently represented in the stub.

With that being said, I agree that perhaps we can do better but I am not a mypy maintainer. So yes please open a new issue asking for this feature.