Ignore reportUnknownMemberType on external depenencies

[nilehmann]

Hi, I'm using pypdf in a project and some of the public api has missing generics. I would like to enable reportUnknownMemberType in my own codebase, but ignore it if it comes from an external dependency is that possible?

[erictraut]

The reportUnknownMemberType already applies only to your own code. Pyright doesn't report errors in code files that are outside of your code base.

The purpose of reportUnknownMemberType is to flag cases where you are accessing an attribute whose type is Unknown (i.e. an implicit Any). If you're importing untyped libraries, it's generally not practical to enable the reportUnknown... diagnostic checks unless you provide your own type information for those libraries (in the form of custom stubs). For information about type stubs, refer to this documentation.

[nilehmann]

pypdf is not untyped. The issue I'm encountering is that part of the public api has an implicit Any (because of a missing generic on IO). I want to treat implicit anys in external code especially so reportUnknownMemberType doesn't trigger when using those external apis.

[erictraut]

Pyright doesn't differentiate between an implicit Any in your code versus an implicit Any in someone else's code. The reportUnknownMemberType is primarily intended to flag cases where an attribute declared in an imported library does not have type information. If this library claims to be typed (i.e. it contains a "py.typed" marker) but is missing some type information, please report that to the library's maintainer.

In the meantime, if you want to work around this issue, you could generate type stubs for the library using pyright's stub generator. You can then augment these stubs to fill in any missing type information that your program relies on.

[nilehmann]

I already reported the issue in pypdf, so yes I was mostly looking for workarounds. The stub generator sounds useful, thanks for the suggestion!

Would it be possible though to implement an option to silence reportUnknownMemberType selectively in these cases you don't have control over the code? But being honest I don't know what that would look like. Maybe treat implicit anys explicitly on a per-module basis?

[erictraut]

Would it be possible though to implement an option to silence reportUnknownMemberType selectively in these cases you don't have control over the code?

No, not really. When analyzing a member access expression (an expression of the form a.b), a can be an arbitrary expression and can evaluate to combinations of types (e.g. a union of classes or a transformed type that results from a decorator).

If you are using libraries that are untyped or partially typed, I recommend against using the reportUnknown... strict-mode diagnostic rules.

[shaperilio]

I have my virtual environment both in exclude and ignore in my configuration. Shouldn't this silence these errors if the code comes from there (i.e. it's a third party library)?