-
Notifications
You must be signed in to change notification settings - Fork 768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to disable "code is not reachable" warning and greying out the code? I find this feature to be unreliable quite often. #248
Comments
We don't have any way to disable that, no. Can you provide some examples of how this feature is unreliable? For auto-imports, see: #64 (comment) |
Thanks for the reply! Unfortunately, I cannot provide details, since I'm working on a proprietary code. I'm pretty sure "code is unreachable" warning is generated due to how the code is structured, and, unfortunately, pylance analyzer doesn't dig deep enough. |
Here is one example I'm hitting. We have a base class with a method that's expected to be overridden by children, and the base class also has another method that calls the (presumably overridden) base method. Herein lies the issue: PyLance seems to see our NotImplementedError on the base/non-overridden version of the method and doesn't realize that what we're referencing is in fact the overridden version. See the comment in
|
Thanks for providing the example. This is the most common cause of code being marked as unreachable. In your example, the There are two ways to work around this issue:
|
Thanks for a constructive reply! We have a lot of similar to @amachanic 's situations, and it would be a pain to rework everything to accommodate PyLance reachability analyzer. I'd definitely prefer to just disable it for these kind of projects. I'm sure a lot of people would welcome an additional PyLance option to control this setting. :) |
The reachability analyzer doesn't ever produce errors or warnings, so the worst thing that happens if you decide not to change your code is that you will see some text grayed out in your editor. |
Thanks @erictraut. I went with the return annotation and it did the trick. Probably should have had one on there anyway. @yury-tokpanov, it took me less than five minutes to change a few impacted base classes, and it's a nearly zero-risk modification. I highly recommend giving it a shot if the gray text bothers you. |
@erictraut Sometimes not just some text, but all the text, if Pylance didn't correctly analyze beginning portion of the code. @amachanic There are too many cases in my project, and I don't feel saying "adding support for Pylance" is a good justification to other people working on it. |
Happens when you are using if typing.TYPE_CHECKING:
annotation = str
# below code is marked as "unreachable"
else:
annotation = ... # some function, these are used for validating data in pydantic as I am forced to do like this as MyPy throws invalid annotation |
Yes, this is as intended. Pylance is showing you the code that is unreachable from the perspective of its code analysis. The "else" clause in your example above should appear as gray. This gives you a visual clue that it is not being analyzed, and errors within this block will not be reported because it's conditionalized on TYPE_CHECKING. Out of curiosity, why do you need to conditionalize this code? It should be fine to execute the statement |
Pydantic uses annotations for validating data, and if you want to use custom validation for the field without making type-checkers screaming ;) |
If the library you are using doesn't use type hints then you are reduced to 2 options:
Seems a bit odd to me that Pylance would make an opinionated decision on this sort of thing. EDIT: There is actually a 3rd option |
Library code doesn't need to contain type annotations to avoid this condition. If it makes proper use of It is important for Pylance to infer when a method or function is a "NoReturn" type. Failure to do this will result in false-positive errors because it will analyze code that is not meant to be executed. It's a tradeoff between false-positive errors (something that we try hard to avoid) versus grayed-out text when using a library that is missing annotations and proper use of |
@erictraut I understand the motives, but it's infeasible to do what you suggest in all of the Python code out there. Why not just give a user an option whether to show results of reachability analysis in UI or not (meaning disabling graying out)? Otherwise, Pylance is great, it's fast and gives useful suggestions, but having sometimes significant portion of the code greyed out is annoying at least. |
As I mentioned, disabling reachability analysis will produce more problems than it solves. One potential solution is to provide a setting that allows you to disable the reporting of unreachable code (i.e. don't show any gray text), but you can already effectively do that by adjusting your theme settings if the gray text really bothers you. |
That was an really clear explanation :) It seems that the main issue is that If there was a setting, it would be to make |
After thinking about this further, I think it's reasonable for Pyright to assume that if a function meets all of the criteria below that it should be considered an abstract method for purposes of type inference:
I've changed Pyright to infer the return type of such methods as "Unknown" rather than "NoReturn". This should address most of the cases that have been cited. This change will be in the next version of Pyright and Pylance. |
This issue has been fixed in version 2020.9.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#202090-3-september-2020 |
Another example is when using with suppress(AttributeError):
return something.a
return something_else pylance will not understand that the suppress context manager is basically doing a try/catch pass and mark |
Not sure if this is by design, or a bug, but this doesn't work for methods marked as @classmethod. Example: class Test(object):
@classmethod
def do_something(cls):
val = cls.get_value()
print(val)
@classmethod
def get_value(cls):
raise NotImplementedError
|
I'm able to repro the problem using the above code snippet, but it only happens with Pylance (not with Pyright), and it seems to happen intermittently. In other words, I can make it go away by making a small edit in the file. These symptoms indicate there's a bug related to type evaluation ordering. Pylance's semantic token highlighting feature tends to cause the types of identifiers to be evaluated in a different order than they otherwise would. In theory, the order of evaluation shouldn't affect the type evaluation results, but we have had bugs in the past where this is not the case. I'll need to look into the problem more deeply. |
As I suspected, there was a bug that resulted in different results depending on the order of evaluation. The fix will be in the next release. Thanks for reporting the problem. |
This issue has been fixed in version 2021.2.1, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202121-10-february-2021 |
@jakebailey hey, was there any working done on providing such a setting? Or how do I can adjust my color-setting of my theme to not show greyed text? unfortunately the greyed text influence the readabilty of the code (color-wise) |
We don't have plans to provide a setting to disable this. |
@StephanDDX it seems VS Code offers this setting called |
@luabud thank you! |
for those interested in making the setting specifically applied for Python only, opening the settings.json file (View > Command Palette... an run "Preferences: Open Settings (JSON)) you can add the following:
|
@luabud This is just what I was looking for! Thanks so much! ps: edit.showUnused should be false, if you are looking to turn it off. |
@luabud Thank you so much for this!!! I also find this an issue and it is not something I can fix because the problem comes from a python module I have no control over. I'm glad there is an alterantive to the our way or the highway seen above. |
@ielenik what is your version of numpy? This might be a bug in the numpy type stubs. Works for me with 1.23.3 |
@OmarAI2003, without the |
Yes, it should have been written before the while loop. Thank you for your assistance |
By default, pyright (the type checker that underlies pylance) analyzes your code assuming the current platform. If you want it to analyze your code for a different platform, you can specify the desired platform via the Here's a simple [tool.pyright]
pythonPlatform = "" |
Still broken. else is reachable: if type_checking:
annotation = str
else:
annotation = float else is unreachable: if TYPE_CHECKING:
annotation = str
else:
annotation = float |
That's by design. TYPE_CHECKING is known for the type checker. |
How do you suggest that I read other projects code when they're structured like this? I have to remove the TYPE_CHECKING check each time to get types within the function. if TYPE_CHECKING:
def foo(arg: str = 'whatever'):
...
else:
def foo(arg: str = 'whatever'):
x = 5
y = 2
z = 1
return x + y + z |
I would assume most people write libraries with the intent that you don't look at their source. I would assume in that example you gave, they're defining the function under the TYPE_CHECKING branch because it's easier to describe the return value of |
I was going to ignore this and just assume that I was in the wrong but after dealing with this constantly it has been driving me crazy. The library does not get to decide what I should and should not have access to. In fact, I first discovered this when trying to diagnose a bug where a method was mistakenly returning It is beyond frustrating that perfectly working code is supposedly "unreachable". |
You could log an issue on the library then. If the library author is not returning the correct types for their functions, it would be a bug on them to fix. |
Everything in the image I posted is correctly typed. Enabling plyance reduces the functionality of vs-code since it completely disables all interaction with the function since it thinks the code is unreachable. I may as well be using Notepad. |
Sorry now I'm confused. Pylance is getting the wrong types then? Do you want to open another bug? I thought the original problem was the If the complaint that some code is marked as unreachable (and the types are computed correctly) but you want it to just skip the unreachable behavior, that would be an enhancement. You could also open a new issue for that as well. I don't think it would work though. If Pylance thinks it's unreachable, it can't compute the types of anything in that section. As far as Pylance is concerned, everything has a type of 'Never'. |
I guess what I'm asking is do you think Pylance is computing types incorrectly or not? |
The problem is when inside a if TYPE_CHECKING:
def foo(exp: float = 5.0) -> float:
...
else:
def foo(exp: float = 5.0) -> float:
x = int(5)
return x * exp x is an int here: |
Using pylance with projects that make use of
Without:
|
No description provided.
The text was updated successfully, but these errors were encountered: