Mypy: Don't complain about missing return with `Optional[<type>]`

[alehander92]

from typing import Optional

def s(e: int) -> Optional[int]:
    if e > 2:
        return 4

s(2)

Currently mypy complains about missing return here and adding return None in the end of the function fixes that. However I think that's undesirable:

• It's not actually catching a bug: it's a false positive. False positives are bad as they lead to lost time and confusion
• It motivates people to put a useless return None line (even return doesn't work) which is just noise in the program code in this case
• It invalidates core Python behavior: since the dawn of time, no return, return and return None mean absolutely the same in each function, but mypy only recognizes one of those forms in this case.

Obviously that seems like a simple example, but I have a longer if/elif function where mypy just says missing return on <first line of function> which has two issues : it's not a type bug, and mypy doesn't the invalid branch

[gvanrossum]

This is a style issue. There's something in PEP 8 that says you should have an explicit return None in such cases.

[MicaelJarniac]

For anyone looking at this later, I think this is what they were talking about:

PEP 8 - Programming Recommendations

Be consistent in return statements. Either all return statements in a function should return an expression, or none of them should. If any return statement returns an expression, any return statements where no value is returned should explicitly state this as return None, and an explicit return statement should be present at the end of the function (if reachable):

# Correct:

def foo(x):
    if x >= 0:
        return math.sqrt(x)
    else:
        return None

def bar(x):
    if x < 0:
        return None
    return math.sqrt(x)

# Wrong:

def foo(x):
    if x >= 0:
        return math.sqrt(x)

def bar(x):
    if x < 0:
        return
    return math.sqrt(x)