Pylance-release: Don't show "not accessed" / graying out for "required" method parameters

[Carl1590]

Why does Pylance grey-out the "self" parameter when i don't use it in the method and shows this when I hover over it:

[erictraut]

Variables that are not referenced are colored in gray as a subtle hint that they haven't been accessed. This can sometimes indicate a bug. If you intended for this symbol to be unaccessed, you can ignore the subtle clue. This behavior is consistent with other language servers.

If you find the grayed-out text annoying, you can adjust your color theme settings to display the same color as normal text (in your case, white).

[jakebailey]

This would be a behavior change, but I think it may be an improvement to not gray out "required" parameters (e.g. self, cls, things needed to properly overload / implement interfaces), as they aren't helpful in those cases.

[janosh]

... I think it may be an improvement to not gray out "required" parameters...

@jakebailey I agree. Came here to suggest exactly that.

[mdavezac]

There is also the case where self is accessed indirectly via super. Those are still diagnosed as not accessed.

[yohan-pg]

It would be nice if we could mark variables, say by naming them with a leading underscore, to indicate that having no accesses to them is OK.

[erictraut]

Pylance never emits an error for an unreferenced parameter.

By default, it also doesn't emit an error for an unreferenced variable, although you can enable the reportUnusedVariable diagnostic rule if you'd like. If this rule is enabled, it will not emit an error if you name the variable _ (single underscore). That's the convention within the Python community to indicate that a variable is intentionally unused. A longer variable name that begins with a single underscore is used to indicate a "private" symbol — one that is not intended to be used outside of the class or module in which it appears.

[yohan-pg]

Thanks for your answer. You are absolutely right that _ prefixes signify private access in python; I mostly used this as an example since it has precedent in other languages. The only problem with replacing the entire names with an underscore that pylance flags duplicate parameters even if they are underscores (Duplicate parameter "_"). Perhaps this could be changed?
EDIT: it just occurred to me that the duplicate parameter error also occurs at runtime, so of course that's not really an option.

I understand that graying out variables is mostly meant as a subtle cue rather than a real warning. However, unused variables are so often a symptom of real errors that gray variables name really become nagging.

[jaapz]

Prefixing with _ is more often used as a way to "mark" a variable as private, not as a way to indicate it explicitly not being used.

Apart from that, prefixing self and cls with _ would be counter to what the python community does anyway so I don't think that rule applies here. self is always there in methods, and very often it is not accessed. Emitting a message like this is not helpful, and is even a bit annoying. Whether it's an "error" or a "helpful message" doesn't really change that.

In itself, this rule (x is not accessed) is very helpful in all other cases so I'd rather not disable it entirely.

EDIT: i read that wrong, you meant replacing the entire variable name with _, but the point still stands: that's not convention so it would be very strange for pyright/pylance to replace the self and cls with _, and that also doesn't agree with pep8

[erictraut]

Pylance does not emit a diagnostic message for this condition. It simply grays out the text which is a subtle visual queue that the variable is not accessed. Are you seeing an actual diagnostic message (like an error or warning) somewhere?

[pzelnip]

This would be a behavior change, but I think it may be an improvement to not gray out "required" parameters (e.g. self, cls, things needed to properly overload / implement interfaces), as they aren't helpful in those cases.

I agree with this, whereas the OT was removing the greying out altogether. I find the greying out useful in the general case, but with "required"/conventional arguments I find it an annoying distraction. That is, in this snippet:

class Foo:
    @classmethod
    def bar(cls, somearg):
         return 42

I'd expect somearg to be greyed out, but cls to not be greyed out.

[jaapz]

Pylance does not emit a diagnostic message for this condition. It simply grays out the text which is a subtle visual queue that the variable is not accessed. Are you seeing an actual diagnostic message (like an error or warning) somewhere?

In my case (using coc.nvim) it's a bit more distracting as the color scheme doesn't just gray things out but also puts a marker on every line and underlines it. You could argue that's my problem and nvim should highlight things like this more subtly, but that's not the point.

Like @pzelnip says, it's highlighting stuff as "possibly shouldn't be here", whereas it absolutely should be there to conform with how Python does (class)methods.

[janosh]

This would be a behavior change, but I think it may be an improvement to not gray out "required" parameters (e.g. self, cls, things needed to properly overload / implement interfaces), as they aren't helpful in those cases.

@jakebailey Just in case you weren't thinking of ABC when you wrote this (although I'm guessing you were), Pylance should also not gray out any variables in signatures of abstract methods:

[ProgrammingLife]

Is there any solution on this?

[janosh]

@ProgrammingLife Not yet. Feel free to upvote the original issue to let the Pylance team know it's important to you.

[jakebailey]

The next release changes the behavior such that the following cases are no longer marked as "not accessed":

• self and cls in methods.
• Parameters for methods explicitly marked as abstract.
• Parameters for methods defined in Protocol classes.
• Parameters in @overload decorated functions.

I think this should cover all of the cases where either it's "required" (makes Python mad if you omit it) or is a part of defining a contract (where the parameters are a part of that definition).

Thanks for the feedback.

[jakebailey]

This issue has been fixed in version 2021.4.2, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202142-21-april-2021

[jaapz]

Thanks for fixing this!

[disrupted]

Nice to see this being adressed in the latest release, thanks!

[LeonardoRick]

I'm having similar issues with a lot of my annotations (@). Is there a issue already opened to that?

[jakebailey]

If the behavior differs from what I defined above, then a new issue would be appreciated.