Skip to content
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

Usage of namedtuple._replace should not generate warning #1454

Closed
matangover opened this issue Jun 16, 2021 · 5 comments
Closed

Usage of namedtuple._replace should not generate warning #1454

matangover opened this issue Jun 16, 2021 · 5 comments
Labels
enhancement New feature or request fixed in next version (main) A fix has been implemented and will appear in an upcoming version

Comments

@matangover
Copy link

Environment data

  • Language Server version: 2021.6.1
  • OS and version: macOS 10.15.7
  • Python version: 3.8

Expected behaviour

Pylance should not warn on when calling _replace on a namedtuple.

Actual behaviour

Pylance generates a warning: "_replace" is protected and used outside of the class in which it is declared.

Code Snippet

from typing import NamedTuple
class MyTuple(NamedTuple):
    field1: int
    field2: str

MyTuple(1, 2)._replace(field1=3)

Notes

The _replace method is documented, along with other fields that begin with underscore and are not private. I can guess that the reason why the prepended an underscore to these members' names is to not clash with user-defined field names in the namedtuple.

Probably Pylance should keep a whitelist of members that start with underscore but are not private.

@erictraut
Copy link
Contributor

We generally avoid hard-coding knowledge of specific classes, functions or members within Pylance because it's not a scalable approach. We might consider doing it in very special circumstances if we receive a lot of feedback.

In this case, the error is emitted only if you enable the reportPrivateUsage diagnostic rule, which is off by default. So you have the option of not enabling this rule, silencing it for a file using a # pyright: reportPrivateUsage=false comment or silencing it on a line using a # type: ignore comment.

@erictraut
Copy link
Contributor

Thinking about this a bit more, the _replace method is declared in the typeshed std stubs. Type stubs are meant to document the public interface contract for a library, and library authors will generally choose to omit private methods and attributes because they are considered "implementation details". In cases where a library author explicitly chooses to include a method or attribute whose name starts with an underscore, I think it's reasonable to assume that they intend for it to be a public symbol. Following that logic, I've changed the logic for the reportPrivateUsage diagnostic check to suppress the check if the method or attribute is declared within a type stub file.

@erictraut erictraut added enhancement New feature or request fixed in next version (main) A fix has been implemented and will appear in an upcoming version and removed triage labels Jun 16, 2021
@bschnurr
Copy link
Member

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

@silriozs
Copy link

silriozs commented Feb 2, 2022

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

This change doesn't seem to include the type name declared in stub files. Some type names, e.g., hashlib._Hash and curses._CursesWindow, are still reported reportPrivateUsage when used. And they are important for writing type annotations for objects come from those libraries.

Language Server version: Pylance language server 2022.1.5 (pyright 8d096292)

@erictraut
Copy link
Contributor

This change was specifically for private class members. I think it's reasonable to add support for module-level symbols as well. I'd appreciate it if you would file a new enhancement request to track this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fixed in next version (main) A fix has been implemented and will appear in an upcoming version
Projects
None yet
Development

No branches or pull requests

4 participants