option to disable unreachable code hints

[DetachHead]

there are many problems with pyright's unreachable code detection. see microsoft/pyright#1951, microsoft/pyright#2231, microsoft/pyright#1531, microsoft/pyright#2258

it would be nice to have an option to disable unreachable code warnings. especially since my project already uses mypy to detect unreachable code anyway.

[erictraut]

Pyright never issues warnings or errors for unreachable code, so there's really nothing to disable here.

The LSP standard supports a special type of optional "hint" that can be used to indicate that a text range should be displayed in a "grayed out" manner. Pyright does use this hint if the client claims to support it. The problem is that some clients interpret this hint incorrectly and display these hints as a regular diagnostic. If these clients don't properly support these hints, they should either ignore them or not request them in the first place.

[jakebailey]

Judging by the issue history here, I believe they are using VS Code, though potentially not Pylance.

[erictraut]

@DetachHead, perhaps I misinterpreted your request then. Could you provide an example of where you are seeing a warning or error diagnostic for unreachable code?

[DetachHead]

@erictraut the error level (info, warning, error, etc.) isn't really relevant to the problem here imo. the issue is that the "hint" or whatever it's called is incorrect in many cases.

it'd be like saying a hint like this from the editor isn't a problem simply because it's not a warning:

(note: this is a fake screenshot)

like, not only is that not correct but it's also probably the lsp causing it and not the editor.

so in this case, this check implies that it's possible for both branches of the statement to run. why would i write a check like this otherwise? if there's no way to tell the editor that there's more than one supported python version such that neither of these branches are reported as unreachable, i would like an option to disable these hints entirely.

if sys.version_info < (3, 8):
    print("🧓")
elif sys.version_info == (3,10):
    print("✔")

and in this case, the hint is obviously 100% incorrect. even though it's obviously doing this because of the type checker, it should have logic to not report this hint on the TYPE_CHECKING variable. if that's not possible/feasible, i would like an option to disable these hints entirely.

[erictraut]

OK, thanks for the explanation.

From the perspective of the code analyzer, this code is unreachable, and it does not impact the code analysis. So in that sense, it is not incorrect to indicate that the code is unreachable. The question is whether it's useful to report this to the programmer. I'd argue that it is, but others may see it differently.

Consider the following code:

if sys.version_info < (3, 10):
    foo = None
else:
    foo = "hi"

print(foo.capitalize())

If you run this code in Python 3.9, it will crash, but in Python 3.10, it will run without error. Pylance will correctly report the bug if you have a Python 3.9 interpreter selected but will not show any errors if you have a Python 3.10 interpreter selected. That's because the statement foo = None is unreachable if you are running in Python 3.10. I find it's important to understand what code is considered reachable in different modes.

When you hover over the grayed-out text, you currently see the text "Code is unreachable". Perhaps you would find the grayed-out text less objectionable and less confusing if we changed that text to say something like "Code is unreachable when run in the selected Python interpreter"? Or is it the presence of the grayed-out text that bothers you?

[DetachHead]

i see your point now. i would suggest changing the text to something like "Code is not type-checked" however, since that will also make sense for the if not TYPE_CHECKING scenario as well.

though that still only makes sense for these special cases. obviously "Code is unreachable" is still the more accurate message for something like

if False:
   ...

[MetRonnie]

I had a function with a annotated return type of typing.NoReturn (it calls sys.exit()). In a unit test, sys.exit() was mocked/patched, but Pylance still claimed everything after the function call was unreachable, leading to it being greyed out in VSCode, annoyingly. One solution I found was to defer the import to the test function, with a type annotation beforehand to override the real one. I.e.

# foo/bar.py
def myfunc() -> NoReturn:
    ...
    sys.exit()

# tests/test_bar.py
def test_myfunc():
    myfunc: Callable
    from foo.bar import myfunc
    ...

[MetRonnie]

This no longer works, instead had to use cast:

from typing import Callable, cast
from foo.bar import myfunc

def test_myfunc():
    myfunc = cast(Callable, myfunc)
    ...

[MetRonnie]

This no longer works either ☹️

[DetachHead]

that works for me. maybe try assigning it to a variable with a different name, it might be keeping the narrowed type from its initial assignment

from typing import Callable, cast
from foo.bar import myfunc

def test_myfunc():
    myfunc2 = cast(Callable, myfunc)

[MetRonnie]

Ah nice, that does the trick

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[DontPanicO]

This warning is not precise with objects initialisation. When I define classes' __init__ I always type hint NoReturn just because that method does not return anything (it's the __new__ method that returns the actual instance). However pylance mark as unreachable the code that access the object after its initialisation:

import typing

class MyObject:
    def __init__(self, some: str, attr: str) -> typing.NoReturn:
        self._some = some
        self._attr = attr

class MyObjectManager:
    def __init__(self) -> typing.NoReturn:
        self._objects: list[MyObject] = []

    def add(self, obj: MyObject) -> typing.NoReturn:
        self._objects.append(obj)

    def create_object(self, some: str, attr: str) -> MyObject:
        obj = MyObject(some, attr)
        self.add(obj)    # this line is unreachable
        return obj    # this line too
        

[MetRonnie]

__init__() does return (None, but you don't need to annotate this).

If it didn't return that would mean it raises or exits, which is what NoReturn is for.

[erictraut]

You're using NoReturn incorrectly. It is meant to indicate that the function or method never returns — that it raises an exception along all code paths, executes an infinite loop, or exits the process. The name NoReturn is confusing, which is why an alternate (and now preferred) name of typing.Never was added in Python 3.11.

In your example above, you should be using a return type annotation of None because that is the type of the object those methods are returning (implicitly).

[DontPanicO]

Thanks. I saw it used as in my example once and I made the mistake to not look at its documentation.

[DetachHead]

pyright now supports this using the enableReachabilityAnalysis option (i assume this is in pylance too but i haven't checked)

btw basedpyright supports a more flexible version of this option called reportUnreachable which allows you to report it as an error. i personally think it should do that by default, since code marked as unreachable is not typechecked. but for the reasons mentioned in my original post this is very often a false positive so it should be reported to the user as an error to ensure they're made aware when potentially large chunks of their code are not being type checked at all.

[silverwind]

pyright now supports this using the enableReachabilityAnalysis option (i assume this is in pylance too but i haven't checked)

This works to suppress all these hints, but I would prefer to suppress these on a case-per-case basis using # type: ignore or similar inline comments, but those currently have no effect on these hints. Ideally I would prefer something like this:

# type: ignore [reachability]

[DetachHead]

in basedpyright you can configure reportUnreachable to "warning" (which is the default), which makes unreachable diagnostics look like this:

and you can suppress it with a pyright:ignore/type:ignore comment:

[silverwind]

Hmm, that does not seem to work in Sublime Text, using LSP-pyright, but if it does work in VSCode, it's likely a bug in LSP-pyright.

[DetachHead]

im talking about my fork of pyright called basedpyright. if you want this functionality in sublime text, check out LSP-basedpyright

[silverwind]

I see. I gave it a try but my first impression is that it shows way more errors than pyright did. Might be a configuration thing. But let's not derail this thread further.