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

Decide on the type annotation for non return functions #3411

Closed
hackaugusto opened this issue Feb 5, 2019 · 6 comments
Closed

Decide on the type annotation for non return functions #3411

hackaugusto opened this issue Feb 5, 2019 · 6 comments

Comments

@hackaugusto
Copy link
Contributor

The definitions bellow are equivalent:

def a() -> None:
    pass


def b():
    pass

We need to pick one to keep the style consistent.

@hackaugusto
Copy link
Contributor Author

vote

def a() -> None:
    pass

@hackaugusto
Copy link
Contributor Author

vote

def b():
    pass

@palango
Copy link
Contributor

palango commented Feb 6, 2019

I think I was partly wrong in saying that -> None is inferred. Especially when running mypy with the --disallow-untyped-defs it complains when functions do not have that annotation.

@LefterisJP
Copy link
Contributor

--disallow-untyped-defs it complains when functions do not have that annotation.

Well this argument explicitly asks all function defs to be typed ;)

@palango
Copy link
Contributor

palango commented Feb 6, 2019

Yes, but I always assumed that no return type annotation implies -> None.

@ulope
Copy link
Collaborator

ulope commented Feb 13, 2019

No, no annotation implies -> Any.
The only exception are __init__ methods with parameters that are annotated, those automatically default to -> None (long issue discussion about that 'feature')

@konradkonrad konradkonrad changed the title Decide on the annotation for non return functions Decide on the type annotation for non return functions Feb 14, 2019
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

4 participants