Support hiding "private" variables/attributes for auto complete

[marsfan]

While Python does not technically have private variables, it is a standardized in PEP8 that single and double underscores at the start of a variable name means that the variable is for internal use only. Some Python IDEs support this, and do not display variables with such prefixes outside of their scope. It would be nice if there was a setting in VS code to enable this behavior.

Source: https://www.python.org/dev/peps/pep-0008/#id36

[karthiknadig]

Can you clarify if this is in completions or debugger or both?

Thank you for the suggestion! We have marked this issue as "needs decision" to make sure we have a conversation about your idea. We plan to leave this feature request open for at least a month to see how many 👍 votes the opening comment gets to help us make our decision.

[Mirandatz]

@karthiknadig

Hi, I am not the original poster, but I believe I could (try to) clarify.
My understanding is that this is related only to completions.

[rost-git]

Whould be nice to have something like:
"python.analysis.internalVariables": "visible" | "hidden" | "greyed-out" // visible as default

[marsfan]

@karthiknadig Somehow I never saw your message until now (over a year later). @Mirandatz is correct, this would only apply to auto-completion.

[DIGITALCRIMINAL]

"Protected" key is what you're looking for?
You can add this to your launch.json configuration

"variablePresentation": {
    "class": "group",
    "function": "group",
    "protected": "group",
}

You can also do the following below to group all variable types.

"variablePresentation": {
    "all": "group",
}

[q-wertz]

Thanks for the hint, works like a charm. Only problem is, that one cannot set this globally…

[Mirandatz]

@DIGITALCRIMINALS

Sadly this (apparently) does not affect Intellisense

[luabud]

Apologies for the confusion, the issues I had liked above was for debugging and not auto completion. I tweaked the title of this issue to be a bit more clear.

[PolarBean]

Any way to achieve either hiding private methods in intellisense or at least showing them last rather than first?

[debonte]

Any way to achieve either hiding private methods in intellisense or at least showing them last rather than first?

They are currently sorted last. I'm not sure when this changed.

If you'd prefer that they be omitted from the suggestion list, please up-vote this enhancement request: #4258

[idan22moral]

I'm facing a similar problem with private attributes in pydantic:

As you can see, I define a model (class, dataclass to be more specific) consisting of public and private fields.
When Pylance hints me with the function's signature, I see the private attributes in the signature too.

But when I got to get the fields auto-completion, I now see public fields only:

There is one place where this verbose fields list is acceptable, and it is the class-preview block on hover:

That's because it shows a preview of what the model actually consists of, and it is not a function parameter list.

@debonte would you say this example is related to the discussed enhancement request? or should I open a new separate issue?

[debonte]

@debonte would you say this example is related to the discussed enhancement request? or should I open a new separate issue?

@idan22moral, please open a separate issue. It's not clear to me that we should ever hide parameters in signature help. You're welcome to argue for your desired behavior in a separate issue though.

There is one place where this verbose fields list is acceptable, and it is the class-preview block on hover:

That hover info isn't for the class, but rather for the generated __init__ method. And there again, I don't believe we should be hiding any parameters. The hover info for the Magic class just looks like this:

Btw, Pylance's support for pydantic's data classes comes via their use of dataclass_transform where PrivateAttr is not listed as a field specifier. The only field specifier listed is Field.

If you switch from PrivateAttr to Field as shown below, you will get the signature help behavior that you're looking for even if the private field doesn't have a leading underscore. With this change, Pylance isn't hiding the _private_field parameter in signature help. It actually doesn't believe that there is a _private_field parameter on __init__ at all -- that's what init=False is specifying.

from pydantic import BaseModel, Field

class Magic(BaseModel):
    _private_field: str = Field(init=False, default="blabla")
    regular_field: str

Signature help:

Hover on __init__ usage:

[idan22moral]

@debonte I've just finished writing my proposal to Pydantic regarding the discussed behavior, and now I see your comment. Funny timing 🤭

After some digging (since Pydantic internals, dataclasses and Pylance+Pyright are new areas for me),
I came to the understanding of exactly what you described. So thank you for the validation.

As you said, the problem is not with Pylance/Pyright, but the field specifiers listed by Pydantic.

Thanks again for your informative comment!