Is it possible to add a setting to disable is not a known member of module to Pylance?

[emirkmo]

Rescuing a highly upvoted request from the general numpy typing issue:

There are other packages with this same problem (i.e. Pysam). Is it possible to add a setting to disable is not a known member of module to Pylance?

Originally posted by @ggydush-fn in #150 (comment)

The problem

The issue is the overly-aggressive error:

"is not a known member of modulePylance [reportGeneralTypeIssues]"

There are thousands of widely used libraries where this issue persists, even if it may be fixed for numpy. It would be great to be able to easily disable this per package. For example, I routinely use astropy, among many other packages, and the code is littered with these errors. Makes coding in VS code with pylance typing support a chore.

Desired/proposed solutions:

• Ignore is not a known member of module for a specific module as a setting, or at import.
• Lower severity of is not a known member of module to an info from an error, as a setting.
• Ignore is not a known member of module for all "third-party" libraries as a setting.

None of these solutions should be default as it can promote bad practices and miss obvious mistakes, but it would be great to be easily set up such options.

Related issues

With upvotes and requests detailing roughly the above:
#106
#150 - The numpy one.

[erictraut]

This error appears only if you enable static type checking, so I presume that you have set python.analysis.typeCheckingMode to "basic". The purpose of static type checking is to report type consistency violations in your code. This requires accurate type information in libraries (or type stubs that describe the type information for a library). If you don't want to use static type checking, you can disable it by setting python.analysis.typeCheckingMode to "off".

[emirkmo]

Hi @erictrait, I of course want to enable type checking in the rest of my own code, but I do not want this specific error to dominate the issues. I need a way to selectively ignore this without littering the code with # type: ignore
wherever I am using a non-conformant 3rd party library.

The user story, if you are curious is something like this:

1. Decide to develop a program that uses a non-conformant third party library (3pl) e.g., astropy.
2. Your own methods, classes, etc. are type annotated to help with development.
3. (Optional) You add type hints for non-conformant 3pl methods as necessary, and use them in your codebase. For example, by decorating the 3pl methods or type-hinting the outputs of the 3pl methods after saving them to a local variable. You now have 95% of the benefit of python static type checking!
4. However, if you enable even basic (not strict obviously) type checking, the errors in your code base are cluttered and dominated by the is not a known member of module. It clutters the screen with red highlights, error warnings in the summary, and negatively affects the use of soft static type checking for code development.
5. There are no workarounds except for manually ignoring all type errors for the affected lines, even if you only want to ignore this specific type error and no others. This also messes with code formatting if you want to isolate the lines and makes code less readable.

Thus, it would be highly desirable to have a way to selectively ignore this specific error in one of the ways mentioned above.

[erictraut]

Thanks for the additional details. Here's what I recommend as a workaround.

Create a local type stub called typings/astropy/__init__.pyi. Within that file, add:

def __getattr__(name: str) -> Any: ...

This tells the type checker that it should allow access to any attribute within this module.

You can also add type annotations for other astropy methods or classes in this type stub file if desired. The key part is the __getattr__ function at the module level.

[maciejmatczak]

@erictraut, I happen to face that with with openpyxl:

Which complaints as:

... while adding explicit import openpyxl.styles clears the error:

I have some python.analysys. settings set, though:

  "python.analysis.watchForLibraryChanges": false,
  "python.analysis.diagnosticMode": "workspace",
  "python.analysis.typeCheckingMode": "basic",

Well, code works, so I assume the analyzer should as well. Does this setup have some influence over how Pylance indexes/analyzes the libraries?

[erictraut]

@maciejmatczak, if you want to access the submodule openpyxl.styles, you should import it within your code. The openpyxl.__init__.py source file doesn't import the styles submodule. It might be getting imported indirectly by some other submodule, but that is incidental, and your code should not rely on this behavior. A small change in the library could result in that behavior changing, and your code would subsequently break. The correct fix is to include an import openpyxl.styles statement in your code.