error "does not return a value" where method really should not return a value

[kurtgn]

An example:

from typing import Optional

class A:
    def optional_return_1(self) -> Optional[str]:
        return self.none_1() or self.none_2()

    def none_1(self) -> None:
        return None

    def none_2(self) -> None:
        return

gets me:

mp.py:7: error: "none_1" of "A" does not return a value
mp.py:7: error: "none_2" of "A" does not return a value

Funny thing is, when I change Optional to None - everything works fine.

Is this a bug or this should be typed somehow differently?

(mypy version 0.670)

[JelleZijlstra]

Mypy assumes that the return value of methods that return None should not be used. This helps guard against mistakes where you accidentally use the return value of such a method (e.g., saying new_list = old_list.sort()). I don't think there's a bug here.

[TristanCacqueray]

a type checker would say "this function returns none, and the function you are calling returns none, therefore, the types match". Is mypy also doing code style?

[SpamapS]

@JelleZijlstra Sorry but that's completely bonkers. None is a very useful VALUE, and should not receive any special treatment from the type checker, period. Of course, if one tries to use methods/attributes that None does not have, we should see a mypy error, but if I use it as a return, that's completely congruent with the point of None. I would urge you to re-open this and consider fixing it.

[gvanrossum]

@SpamapS Please remain courteous. This decision to make this distinction (between return and return None) was made long ago and for good reasons, and we're not going to change it.

[SpamapS]

@gvanrossum understood, and apologies for any offense. I was being true to my feelings, but I don't mean to hurt anyone else's in the process!

Can you please point us to anywhere the reasoning for that is written down? It feels like mypy is suggesting a coding style, rather than just doing type checking, and that just seems counter to the reasons folks might want to adopt mypy.

[davidemerritt]

bump - I'd love to see the reason why? I also just ran into a valid use case for a function that only returns None

[radiantone]

"Mypy assumes that the return value of methods that return None should not be used."

^^^ This makes zero sense at all.

[nick-grout1]

None is a very useful VALUE, and should not receive any special treatment from the type checker

Agree with this 100%, by suggesting a different return type mypy is making a code style recommendation.

[radiantone]

I would recommend monkey patching your local install of mypy to correct this obvious ridiculousness since the developer has surreptitiously closed the ticket and doesn't want to hear any community logic (from experts).

[motherofcoconuts]

Also agreed 100% with the comments here. This assumption that a return value of None should not be used does not make sense and I am happy to point to a number of valid use cases where this create issues.

[JelleZijlstra]

The stream of "me too" comments isn't very helpful in changing our minds. Here's what you can do if you want this behavior to change:

• Present a persuasive use case where the current behavior causes problems. (I don't find the OP's example compelling.)
• Explore how other Python type checkers handle this area.
• Create a draft implementation of the change you're seeking. The mypy test suite and the mypy-primer tool (which runs mypy on a lot of open-source code) should give a better view of the impact of the change.

[erictraut]

FWIW, pyright does not ascribe any special meaning to a return type annotation of None. It treats a None return type like any other return type.

@JelleZijlstra, you said that the main reasoning behind this special-case handling in mypy is to catch bugs where callers are making use of a None return value inappropriately. Isn't that already handled through type analysis at the call site? If the caller is using a None return value in a context where None is not allowed by the type rules, the type checker will already flag it as an error. I don't understand what class of bugs is being prevented by restricting the implementation of a function from returning None explicitly or implicitly with a simple return statement.

[ScottNotFound]

Just ran into this problem where I was trying to optionally throw an error or return None according to a setting.

Short example:

class Finder:
    def __init__(self, strict: bool = True):
        self.strict = strict

    def raise_or_none(self, e: Exception) -> None:
        if self.strict:
            raise e
        return None

    def find_in_list(self, l: list[str], v: str) -> Optional[str]:
        for item in l:
            if v in item:
                return item
        return self.raise_or_none(RuntimeError('could not find item in list'))

You could also use this pattern to pass None values up a chain of calls or toss the exceptions around like a football. Throwing a type ignore all over the place to be able to use a single function doesn't seem like a great option.

[radiantone]

The stream of "me too" comments isn't very helpful in changing our minds. Here's what you can do if you want this behavior to change:

• Present a persuasive use case where the current behavior causes problems. (I don't find the OP's example compelling.)
• Explore how other Python type checkers handle this area.
• Create a draft implementation of the change you're seeking. The mypy test suite and the mypy-primer tool (which runs mypy on a lot of open-source code) should give a better view of the impact of the change.

Tone deaf