Type checking unreachable code

[decorator-factory]

It seems like mypy and pyright disagree on whether code that's (allegedly) unreachable should be checked.

pyright

pyright-play link

Pyright seems to approach reach-ability a bit differently. Code under an if False or if not TYPE_CHECKING block will be truly skipped from analysis. But some other code paths will have a different effect:

def double(x: int) -> int:
    if not isinstance(x, int):
    #^ Unnecessary isinstance call; "int" is always an instance of "int" 
        reveal_type(x)
        #x: Never ^
        raise ValueError[f"Expected an integer, got {x!r}"]
        #                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        # Expected no type arguments for class "ValueError"
    return x + x

mypy

mypy-play link

On the same code snippet, mypy is completely silent. I discovered this because I was confused that a reveal_type(x) didn't show anything.

what's the "correct" behaviour?

To me the main use case for these "unreachable" checks is for runtime checking of types. Not everyone is using a type checker, and a type checker isn't guaranteed to prevent passing a value of the wrong type to the wrong function (for example by using Any). In that case, I think it makes sense to check the code in that block for errors

But maybe it's going to be difficult to change in mypy because it uses the same "unreachable" label for if not TYPE_CHECKING-style conditions and the "impossible" isinstance?..

[hauntsaninja]

mypy has a --warn-unreachable flag to get mypy to complain about unreachable code. When --warn-unreachable is enabled, mypy's heuristic is that it won't complain about unreachable code that always raises an error, e.g. a raise or assert statement, or does nothing (pass or ellipsis), or is a call expression that resolves to Never. Overall, this works reasonably okay for doing a little bit of runtime type checking.

Your case is a little unfortunate, but we could probably get mypy to check the unreachable statement before breaking out of the block

I think it'd be a good idea for --warn-unreachable to be part of mypy's --strict, since the current behaviour of doing nothing can be quite surprising. I think mypy's approach here is probably due to historical reasons. Although even now, mypy's binder is not sophisticated and trips up on some common cases, so would need to see how that looks in practice

[hauntsaninja]

Let's see what python/mypy#17080 does (it will give you the error you want, when --warn-unreachable is enabled at least)