warn_no_return = False: handle implicit "return None" (not ignoring return type)

[blueyed]

warn_no_return is on by default, but does not take into account that None is returned explicitly.

I think it should maybe only warn if the return type does not include None (i.e. uses typing.Optional).

Given t_mypy.py:

import typing


def no_return_optional(arg) -> typing.Optional[str]:
    if arg:
        return "false"


def no_return(arg) -> str:
    if arg:
        return "false"


a1 = no_return_optional(True)
a2 = no_return_optional(False)
reveal_type(a1)
reveal_type(a2)

b1 = no_return(True)
b2 = no_return(False)
reveal_type(b1)
reveal_type(b2)

mypy --warn-no-return shows:

t_mypy.py:4: error: Missing return statement
t_mypy.py:9: error: Missing return statement
t_mypy.py:16: note: Revealed type is 'Union[builtins.str, None]'
t_mypy.py:17: note: Revealed type is 'Union[builtins.str, None]'
t_mypy.py:21: note: Revealed type is 'builtins.str'
t_mypy.py:22: note: Revealed type is 'builtins.str'
Found 2 errors in 1 file (checked 1 source file)

mypy --no-warn-no-return does not show any error, but should warn/error about the missing return statement / wrong return value for no_return (which is annotated to return str, but might return None).

mypy 0.730+dev.28423cd78062b81365ec9aaa591b4e823af1606d

[JukkaL]

This is by design. warn_no_return excepts an explicit return statement even in functions that return an optional type. The assumption is that relying on the implicit None return is often an error (or at least a code smell).

When the check is disabled, mypy effectively behaves as if there Python had no implicit None return. I can see how this can be surprising, and I may be persuaded that this is not the best way to implement this.

At the very least we could make the documentation more detailed.

[blueyed]

When the check is disabled, mypy effectively behaves as if there Python had
no implicit None return. I can see how this can be surprising, and I may be
persuaded that this is not the best way to implement this.

The main problem I see here is that you are forced to use the default
(warn_no_return = True), since otherwise you are not getting an error with:

def f(a) -> int:
    if a:
        return 1

Disabling the warning is useful/necessary to not change code unnecessarily
when adding type annotations, but currently you are forced to add return None at the end always despite of the setting to not have errors go silent
(btw: return by itself results in "Return value expected").

Therefore I think it would be great if the behavior in this regard could be
changed (as if return None was used), since otherwise disabling the warning
also hides real errors silently.
This would affect the non-default part of the option.

While I'd still prefer to have Optional[…] not cause a warning without an explicit return None by default, I think the above is more important for now, and have changed/clarified the issue title in this regard.

Docs for reference: https://mypy.readthedocs.io/en/latest/command_line.html#cmdoption-mypy-no-warn-no-return

[ilevkivskyi]

FWIW, I am fine with the current behaviour -- "explicit is better than implicit". The error message and the docs however can be improved.

[blueyed]

@ilevkivskyi
Don't you agree that mypy not showing an error with the above example (with warn_no_return = False) is wrong / hiding the error?

[ilevkivskyi]

I don't see a problem if someone opts-in to unsafety and gets an unsafety. (Also this is my final opinion here, I don't have time to write an essay about why/what/etc.)

[blueyed]

Ok, fair enough - I do not want to waste anyone's time of course.
But just to be clear - the option is not named ignore_errors_with_no_return, i.e. it is not clear but surprising that it behaves that way.
I also think that mypy ignoring the fact that Python has implicit returns is a design decision to be revisited, and that should be done before adding a warning to the docs then probably.

[ofek]

I also think that mypy ignoring the fact that Python has implicit returns is a design decision to be revisited

I agree wholeheartedly. From #3974 (comment):

This is a style issue

Indeed, Mypy is overreaching here and enforcing a stylistic choice at the cost of correct language semantics.

This is the only reason I'm not using Mypy 😢

[JukkaL]

The most likely way around this that I can see is adding support for enabling/disabling individual error codes, and giving the relevant error message a specific error code that can be disabled (which would hide all these messages). Now anybody who doesn't like this error can disable the relevant error code.

I'm happy to accept a PR that implements enabling/disabling error codes (we should first discuss how this would be configured in a separate issue).

[ofek]

@JukkaL Thanks! I opened #8975