Enhancement: Allow specification of a list of modules to not do type checking for

[Dr-Irv]

I'm using a third party commercial library, and there are no type stubs provided by the third party. When using mypy, I can put something like this in my mypy.ini file:

[mypy-thirdparty.*]
ignore_missing_imports=True

where thirdparty is the name of the library. Then I know mypy won't complain about not finding stubs for that library.

It would be useful to have an option in pylance that tells it to ignore specific libraries when you know there is no type stub available, and you know that python.analysis.useLibraryCodeForTypes won't help, because the library is provided as a pyd file, so you can't look at the source.

[AloizioMacedo]

Are there any news regarding this feature?

[erictraut]

There's a simple workaround that doesn't require any new settings or configuration knobs. You can create a type stub for the library that contains the following line:

# thirdparty/__init__.pyi
def __getattr__(name: str) -> Any: ...  # incomplete

[AloizioMacedo]

Thanks for the suggestion! That is interesting, but if I understood correctly, it would not work well for groups working together in some repository, for example. It would require everyone to make that change separately, right?

[erictraut]

You should add the stub to a top-level subdirectory called "typings" and check it in to your repo. Then everyone working on the project will benefit from it.

If you would prefer some other directory name (like "stubs" or "type-stubs"), you can override the default name ("typings") using the "python.analysis.stubPath" setting. Or you can use the "stubPath" configuration key in the pyrightConfig.json file.

[AloizioMacedo]

Nice, thanks again! I will try it out tomorrow.

EDIT: Worked perfectly!

[AloizioMacedo]

I've noticed that my typing problems with the library are gone, but the syntax highlighting of VSCode is also gone. I understand this makes sense, but it is an inconvenience I'd rather avoid. I just want the errors related to typing from those libraries to be gone.

For reference, here is an example:
(with the stubs)
vs.
(without the stubs)

Is there a way to avoid this?

[erictraut]

Without type information, the semantic highlighter doesn't know what semantics should be attributed to these symbols. That's the tradeoff.

You have the following choices:

1. Live with the incorrect/incomplete type information inferred from the original library code. As you've observed, this will typically result in false positive errors if you enable type checking because the type checker requires accurate and complete type information.
2. Stub out the libraries in using an empty stub (with a top-level __getattr__ function that indicates all symbols provided by that module are typed as Any). This will eliminate any errors associated with the symbols provided by those modules, but it also "blinds" the type checker, opening you up for undetected errors. As you noticed, it also affects semantic highlighting.
3. Fill out the type stub so it declares type information for classes and functions you care about (those that you use in your program). You can typically generate a "first draft" of such stubs using tools such as the pyright command-line tool. For instructions, refer to this documentation.

[Dr-Irv]

@erictraut I think your are missing the point here. This is about third party libraries. Option (3) above is not developer friendly.

There are MANY third party libraries out there. Most are not yet typed. mypy has an option to specify the list of libraries to skip for type checking purposes. Place that list in a mypy.ini file and you're all set. No need to create a fake stub with __getattr__ for each one.

We're asking for a feature that is equivalent to that mypy option, to make it easy for people to tell pyright to ignore specific third party libraries.

[erictraut]

The option you're asking for is the equivalent of creating a stub library with a top-level __getattr__ (which is option 2 above). Adding an option would be redundant because adding a one-line type stub file already accomplishes this (and is no more of a burden than adding a one-line option in a setting or config file). If we were to add this option, it would exhibit the semantic highlighting behavior that @AloizioMacedo didn't like. Option 3 is the recommended way to address both issues (removal of false positive type checking errors and correct semantic highlighting).

[Dr-Irv]

(and is no more of a burden than adding a one-line option in a setting or config file)

It is more of a burden!!! Adding a one line stub file means that you have to add separate files in your repo for each of the third party libraries that you use, rather than have one central options file that has the libraries you wish to ignore.

Option 3 requires preparing stubs for a 3rd party library, (of which there are many in a typical project). That's a lot of work.

[erictraut]

I guess that your definition of "burden" is different from mine. Creating a type stub file with one line doesn't strike me as a burden. It has the added benefit that you can optionally add additional type information to the file over time (incrementally moving toward option 3 when you see the benefits of doing so). This is how I manage my team's sizable Python code base, and it works well for us.

[AloizioMacedo]

I can understand the benefits of option 3, but my impression is that the main benefits exist if you want to fill in (or correct) typing absences (or mistakes) of certain third party libraries. Option 3 is what I'll probably go with for now.

But there would be a great benefit in a feature that could simply not show typing errors regarding a certain library while not interfering with the highlighting of VSCode.

To give an example, traci has a method traci.trafficlight.getPhase(). The "trafficlight" there is a variable defined in the main file of the package, which accesses a private module _trafficlight and assigns trafficlight = _trafficlight.TrafficLightDomain().

When I create the stub, I must manually go and make this assignment on the main.pyi generated file. And I need this just to get the syntax highlight. This is a convoluted process since I don't want to change the typings of the library, not to mention that I need to understand the inner workings of traci. I just want the highlight and not seeing the errors that come from typing issues of this library.

[Dr-Irv]

I guess that your definition of "burden" is different from mine. Creating a type stub file with one line doesn't strike me as a burden. It has the added benefit that you can optionally add additional type information to the file over time (incrementally moving toward option 3 when you see the benefits of doing so). This is how I manage my team's sizable Python code base, and it works well for us.

And what I am telling you is that what would work well for us is to just have a list of libraries to ignore (and maintain the syntax highlighting, as @AloizioMacedo mentioned above). It also makes using mypy and pyright both in a project easier to do.

I have a project that has 12 external libraries that we do ignore_missing_imports for in a mypy.ini file. We are not going to spend our billable time in consulting to enhance third party library type stubs. So we won't get the additional benefit you mention by using option 3. It would be much easier to just provide a list of libraries to ignore, just like in mypy.

So why can't you support both ways of doing it?

[erictraut]

Semantic highlighting is based on the type information. They go hand-in-hand. You can't say "I want correct semantic highlight but I want to treat all of the symbols from this library as Any for the purposes of type checking so I receive no type errors relating to them". Mypy doesn't offer semantic highlighting, so that's not an issue with mypy.

If we were to implement a configuration option to control this, it would have the same behavior as one-line stub files with a __getattr__ function. We generally don't like adding redundant ways of doing things unless there's a compelling reason to do so. I'm just not hearing a compelling reason here.

The one-line stub files work with mypy as well, so if you're looking for a solution that works across type checkers, it has that added benefit.

[Dr-Irv]

The compelling reason is ease of use. Surveyed my team and they all agree.

[AloizioMacedo]

Semantic highlighting is based on the type information. They go hand-in-hand. You can't say "I want correct semantic highlight but I want to treat all of the symbols from this library as Any for the purposes of type checking so I receive no type errors relating to them".

Couldn't the processes be separated? For example, a configuration for which for the purposes of semantic highlight, run the standard type checking as if there were no custom stub files created. And then pyright and the stub files would only act to raise errors/warnings, not interacting with the semantic highlight. Then your solutions with the stub files etc would work perfectly for me.

[erictraut]

I suppose that's theoretically possible, but that would involve a completely different architecture than the one that pylance / pyright uses. It would also involve double the memory, double the processing, etc., so it's not really feasible.

It would also mean that semantic highlighting information would no longer match that of the type checker, the hover text, the signature help, etc. I think that would be really confusing to have this mismatch.

[admackin]

I'm with @Dr-Irv here – it's a bit painful, and AFAICT we would need to create a .pyi stub for all qualified packages we import from – eg somepackage, somepackage.subpackage etc?. By comparison, mypy lets us set globs like somepackage.*

So if we switch to pyright, we're going to have to use the less optimal setting reportMissingTypeStubs = false meaning that we'll fail to notice some type stubs that could be installed manually I think.

[rchiodo]

Converted this to a discussion item to see how many upvotes it might get.