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

Assume unannotated return values to be None instead of Any (behind flag) #14180

Closed
berzi opened this issue Nov 24, 2022 · 2 comments
Closed

Assume unannotated return values to be None instead of Any (behind flag) #14180

berzi opened this issue Nov 24, 2022 · 2 comments
Labels
feature topic-inference When to infer types or require explicit annotations

Comments

@berzi
Copy link

berzi commented Nov 24, 2022

Feature

Behind a config flag like untyped_return_type_is_none = true, Mypy assumes that a function with no return type, e.g.:

def my_func(i_am_annotated: str):  # Note: no "-> int" annotation
    return 5

Returns None, instead of accepting any return type at face value.

Additionally, while untyped_return_type_is_none is true, disallow_untyped_defs allows functions to have no return annotation if their return type is None.

Pitch

Adoption for the disallow_untyped_defs is difficult, because it requires None to be explicitly annotated. This makes code more wordy in many places where the annotation adds zero value (think of all test functions/methods for extremely popular frameworks like pytest or unittest). This is especially overwhelming for maintainers of large codebases with many tests and existing functions.

Having the flag would give users an option to leave -> None functions unannotated.

Current behaviour would be unchanged if the new flag were not activated, but activating the flag would force users to annotate those functions that do return a value, providing a large but progressive step towards disallow_untyped_defs, reducing the essentially meaningless menial work of adding -> None everywhere.

@berzi berzi added the feature label Nov 24, 2022
@tmke8
Copy link
Contributor

tmke8 commented Nov 24, 2022

Duplicate of #9413
(Though your proposal is fleshed out more)

@AlexWaygood
Copy link
Member

Duplicate of #9413 (Though your proposal is fleshed out more)

Closing as a duplicate of the older issue so that we can keep the discussion in one place rather than split across two issue threads

@AlexWaygood AlexWaygood closed this as not planned Won't fix, can't repro, duplicate, stale Nov 24, 2022
@AlexWaygood AlexWaygood added the topic-inference When to infer types or require explicit annotations label Nov 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature topic-inference When to infer types or require explicit annotations
Projects
None yet
Development

No branches or pull requests

3 participants