error: "x" does not return a value [func-returns-value]

[alexei]

It's been suggested before that mypy makes no distinction between a function that doesn't return anything and a function that returns None explicitly, and simply assumes no return value. I think I understand mypy's approach on this since in practice there's no difference between return, return None, and no return statement at all. I also think it's not fair considering a NoReturn is also available, though I suspect it's because Python's history is longer than that of NoReturn.

But consider a hypothetical example when a developer needs to return None:

@dataclass
class IntBox:
    value: int

    def val(self) -> int:
        return self.value


class EmptyBox:
    def val(self) -> None:
        return None


assert IntBox(1).val() == 1
assert EmptyBox().val() is None

As expected, mypy points out an error: "val" of "EmptyBox" does not return a value [func-returns-value]

In my case such assertions were part of the tests, though I see no harm in wanting to call val anywhere without caring about the return value. E.g. I just want to store the result in a nullable field in a database table.

Considering mypy's current behavior, my solution now is to instruct it to ignore that specific line:

assert EmptyBox().val() is None  # type: ignore

Another option would be to use a sentinel value, but that feels like it's getting out of hand.

My understanding is mypy takes a conservative approach here, so what if there was an alternate mechanism to telling it the developer actually wanted to return a None? For example, what if it considered Literal[None] as a type hint distinct from None? I.e:

class EmptyBox:
    def val(self) -> Literal[None]:
        return None

This would allow mypy (and similar tools - I presume) to keep working as they were, while still allowing an explicit None return value. It looks, at least on the outside, that similar behavior exists for the boolean values:

def the_truth() -> True:
    ...

is not allowed i.e. error: Invalid type: try using Literal[True] instead? [valid-type], but a literal True is:

def the_truth() -> Literal[True]:
    ...

---

While writing this, I'm learning there exists a Never as well. I think Never is interesting, but would not be suitable in my example as I do intend to call val() on an empty box at some point, whereas Never doesn't like return statements.

[erictraut]

Never is an alias for NoReturn; they can be used interchangeably. This type wouldn't be appropriate to use for a function that implicitly or explicitly returns None. It describes a function that never returns control back to the caller (e.g. it raises an exception on all code paths).

As you can see from the other thread you referenced, there are differing perspectives on whether mypy's special treatment of a None return type is justified. For comparison, pyright (of which I'm the primary author) does not treat a None return type specially, so your code sample above type checks without errors when using pyright.

[alexei]

For comparison, pyright [...] does not treat a None return type specially

That is very interesting. I'm reluctant to see this as a feature - that different tools have different interpretations of the same things. It puts me, as a developer, in an awkward position where I don't know which way is true and, instead of being guided by the documentation, I'm adjusting and tweaking my types to silence the type checker rather than seek correctness. I think type checkers should compete on completeness, performance, developer features, not interpretations of the spec. But if the spec is open to interpretation, then perhaps some decisions made a long time are not that rigid and there is room to have conversations about them.

[hauntsaninja]

Consider using --disable-error-code func-returns-value.

It's possible this check no longer has that much value, I'm betting it dates back to the terrible old days before --strict-optional was the default and so caller mishandling of None return would go undetected

[hauntsaninja]

Closing, since the error code can be disabled, and I can't find evidence on our issue tracker that this error bothers people enough that should be off by default

Later edit: there are actually a few issues complaining about this

[alexei]

Can you please confirm that disabling "func-returns-value" doesn't produce other side effects?

[OlegAlexander]

Hello, I'm so sorry to comment on a closed issue. I was also surprised and puzzled by this error when I tried something like this:

from pathlib import Path

[file.unlink() for file in Path(".").glob("*.jpg")]

Mypy error: "unlink" of "Path" does not return a value [func-returns-value].

In this case, I'm deliberately using a list comprehension for the side effects. The list evaluates to a list of Nones. But why is this a type error?

[jaraco]

Perhaps consider re-opening. This issue was somewhat addressed when it bothered the author of #8602. I encountered it when using an expression:

item: Any
items: list[Any]
item in items or items.append(item)

Similar to Oleg, I'm using items.append for its side effect, not for its result. And moreover, the result isn't assigned to anything so I'm particularly not concerned about the return value.