Optional return type is not correctly handled when the function returns without the 'None' value

[realharry]

Bug Report

In Python, "return" and "return None" are equivalent. MyPy handles it correctly in simple situation. For example,

def fn0() -> None:
    return

or

def fn0():
    return

They both pass the mypy check.

However, if you use Optional[T] or the Union type T | None, mypy does not correctly handles the return statement. For example,

def fn1(x: int) -> Optional[int]:
    if x > 0:
        return 1
    else:
        return

def fn2(x: int) -> int | None:
    if x > 0:
        return 1
    else:
        return

They both generate an error:

$ mypy optional_test.py 
optional_test.py:12: error: Return value expected
optional_test.py:19: error: Return value expected
Found 2 errors in 1 file (checked 1 source file)

The lines 12 and 19 refer to the return statements without any specific return values.

To Reproduce

(Write your steps here:)

1. Create a function that returns Optional or Union type which includes None.
2. Return from the function without a return value.

Expected Behavior

The return statement should be treated as return None.
Mypy should not produce an error on a valid Python code.

Actual Behavior

Mypy check fails. See the example above.

Your Environment

• Mypy version used: 0.910
• Mypy command-line flags: none
• Mypy configuration options from mypy.ini (and other config files): none
• Python version used: 3.10.0
• Operating system and version: Ubuntu 20.04LTS

[A5rocks]

I've run into this myself, it's quite annoying.

Nonetheless, there's already been an issue report, and it looks like mypy is going to stay this way (though I dislike it doing this): #7511. Nevermind I confused this internally with a different thing I ran into at the same time :S

[a-reich]

Already discussed here

[realharry]

thanks for the pointers, for both of you. but, I see the two problems slightly differently. #7511 discusses the implicit return. my personal view is (1) implicit return is not a bad thing. it is common in many different languages the problem is when a function mixes explicit and implicit returns. that is not a good practice, in my view but, the explicit return statement is semantically equivalent to return None in Python. I'm new to mypy and I don't have a big picture, but it seems like the problem I'm reporting is different from #7511. the return statement is not the same as the implicit return.

[hauntsaninja]

Closing as per this specific comment on that issue: #7511 (comment) mypy could do worse than enforce rules that are dear to Guido's heart ;-)

[realharry]

I don't think Guido's comment precludes the situation I'm referring to. The code using return instead of return None is PEP8 compliant (which is dear to Guido). and, the --no-warn-no-return flag does not help in this situation.

handling of this particular case by mypy is especially problematic since it does not honor the fundamental principle in python that a function that "does not return a value" is the same as a function "that returns None". mypy should be compliant with the python rules. the programmers do NOT have to change their perfectly valid pythonic coding practice just to use mypy (e.g., just to use add-hoc typing).

Using mypy forces the user to use return None instead of the perfectly valid, and often preferred, return in certain situations (but, oddly, not in certain other situations). For me, its a serious issue, which undermines the "legitimacy" of mypy. ;)

[0xfede7c8]

@realharry I think some mypy people are too fond of pylint ;)