Reconsider stance on Wildcard imports

[Sharpz7]

I know this has been covered before, but a major usecase of wildcard imports is in machine learning. Lots and lots of developers in the AI field use wildcard imports (Take the fastai library for example).

As well as this, Pylance happily gives details of wildcard imports, where as pyright will not. I would love to see this feature implemented, but disabled by default :))

I tried checking for similar discussions, but even after disabling pyrights errors, it says variables are "unknown", rather than actually getting data about the objects like pylance.

Thanks!

[erictraut]

Behavior in pyright and pylance should be the same in this case. Can you provide a concrete example of the problem you're seeing?

When you say "gives details of wildcard imports", what do you mean? In what context? Are you referring to completion suggestions? Auto-import suggestions? Hover text?

[Sharpz7]

Okay. I will do a full walkthrough of my experience. The code sample I am working from has been losely based on this.

Pylance

With Pylance installed, everything works as I would like. There are no configuration changes needed and the wildcard imports are correctly handled.

PyRight

With pyright installed, first I get errors.

and

I added this setting to my vscode config...

"python.analysis.diagnosticSeverityOverrides": {
    "reportWildcardImportFromLibrary": "none",
}

And now I still get all the wildcard imports not being definied.

(My Pyright version is v1.1.265)

[erictraut]

There are two independent issues here. The first has to do with the reportWildcardImportFromLibrary diagnostic check. By default, typeCheckingMode is set to "basic" in pyright and "off" in pylance. When typeCheckingModeis set to "basic",reportWildcardImportFromLibrary` defaults to "warning" rather than "none". That explains part of what you're seeing, and it's expected behavior.

The second issue is whether the types of symbols imported using wildcard imports are resolved. That is unrelated to the reportWildcardImportFromLibrary diagnostic check. The behavior here should be the same between pylance and pyright, so we'll need to explore more to determine why you're seeing different behavior between the two. My working theory is that you are importing from a library that has no type information but for which pylance includes bundled type stubs. To test this theory, I will need more details. Debugging issues from partial screen shots won't work here. I'll need you to provide a minimal, self-contained code sample that exhibits the problem. Your code sample will presumably include an import statement that targets one or more libraries. It would be useful to know which versions of those libraries you have installed.

[Sharpz7]

https://hastebin.com/relavijure.py Here is a self-contained code example.

Here is my poetry project file

[tool.poetry]
name = "fastai-testing"
version = "0.1.0"
description = ""
authors = ["Sharpz7 <[email protected]>"]

[tool.poetry.dependencies]
python = "^3.9"
fastai = "^2.7.9"
duckduckgo-search = "^2.0.2"

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

I think your stub theory is absolutely spot on. Is there a recommeneded way to make stubs specifically for pyright to use?

[erictraut]

Your sample was self-contained but far from minimal. :) But I can work with it.

The issue here is that these libraries are not typed (i.e. they contain no type annotations and don't include a "py.typed" marker file). By default, pyright assumes that any symbols imported from such files are Unknown. However, pyright provides a special mode that can be enabled with the setting useLibraryCodeForTypes that tells it to attempt to infer type information from the Python source code in the library. This is error prone, and we don't recommend using this for type checking. However, it's often good enough for completion suggestions and hover text. For that reason, Pylance enables useLibraryCodeForTypes by default.

A couple of suggestions...

1. Don't use wildcard imports. Seriously, it's a really bad practice and results in fragile code. PEP 8 highly discourages it.
2. If you want to use type checking in your code, you need good type information for the libraries you're consuming. If those libraries don't have inlined type information, then you may be able to find type stubs. Without type stubs, you can try to enable useLibraryCodeForTypes, but your mileage will vary.

[Sharpz7]

Ah okay. I will enable useLibraryCodeForTypes.

And yes, I understand that wildcard imports are bad, and I avoided it without question up to now. But it seems that in the jupyter-notebook, "Data Analysis" World, this is common and used all the time, and I don't want to have to adapt all my code samples from the fastai course and other user created examples.

Thanks for helping out with this :))