Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

__init__ return type should only be annotated if it has no args #47

Closed
mx781 opened this issue Dec 9, 2022 · 5 comments
Closed

__init__ return type should only be annotated if it has no args #47

mx781 opened this issue Dec 9, 2022 · 5 comments

Comments

@mx781
Copy link

mx781 commented Dec 9, 2022

Mypy has not required __init__ to have a -> None return annotation for a while (except in the cases of no-arg constructors). I was able to disable it entirely by monkeypatching SIMPLE_MAGICS, but it feels like a more proper solution that distinguishes between no-arg and some-arg constructors would be appropriate here.

@JelleZijlstra would such a change be trivial to add?

@JelleZijlstra
Copy link
Owner

I would prefer to keep annotating __init__. It's potentially confusing for mypy users when their constructors suddenly aren't typechecked if they have no arguments.

It wouldn't be terribly difficult to skip adding a return annotation to __init__ only if there are typed arguments, though.

@mx781
Copy link
Author

mx781 commented Dec 9, 2022

Yes, agreed the latter is the desirable behaviour - otherwise it ends up adding needless boilerplate. Does the fact that it's not terribly difficult mean we could see this land soon in autotyping, or that I'm welcome to file a PR for it? :P

@JelleZijlstra
Copy link
Owner

No, I'd like to keep the current behavior of always annotating __init__. It's simpler to implement and simpler to understand.

@JelleZijlstra
Copy link
Owner

I'd accept a new option like --skip-redundant-init-annotation though that overrides the default and skips adding the annotation.

@mx781
Copy link
Author

mx781 commented Dec 9, 2022

Alright - I'll see if I can get that to work and file a PR when I do. If I don't reply back in a few days this can probably be closed as a wontfix.

@JelleZijlstra JelleZijlstra closed this as not planned Won't fix, can't repro, duplicate, stale Jan 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants