Open nineteendo opened 1 month ago
@erictraut is the best person to answer this, but I believe it is by design given our import resolution order described here: https://microsoft.github.io/pyright/#/import-resolution?id=resolution-order.
Here are some ways you could fix this:
from .typing_extensions import Literal
typing_extensions.py
into your virtual environment.typing_extensions.py
to your workspace root, your stubPath
, or a location in your extraPaths
, although that will result in a reportShadowedImports
diagnostic.I believe it is by design given our import resolution order
Note that it doesn't complain if I rename typing_extensions.py
to typing_extensions_1.py
.
For an absolute import, if all of the above attempts fail, attempt to import a module from the same directory as the importing file and parent directories that are also children of the root workspace. This accommodates cases where it is assumed that a Python script will be executed from one of these subdirectories rather than from the root directory.
Somehow this step is being skipped for typing_extensions
.
Use a relative import
That won't work, as the libraries can be optionally installed.
Move
typing_extensions.py
into your virtual environment.
I don't think that will make a difference, I'm getting this error if typing_extensions
isn't globally installed. Which is the whole point of this, you can test the code immediately after downloading from GitHub without needing to set up a virtual environment or install dependencies.
Move
typing_extensions.py
to your workspace root, yourstubPath
, or a location in yourextraPaths
, although that will result in areportShadowedImports
diagnostic.
It's very convenient to have the different branches of the repository as subfolders (work trees) of the workspace root.
And typing_extensions.py
must be in <branch>/src/
. Because these paths are arbitrary, I can't specify them.
Shouldn't it only report shadowed imports if it can't find the imported symbol, but it's present in the shadowed module?
I don't want to write from typing_extensions import ... # type: ignore
in every file.
Note that it doesn't complain if I rename
typing_extensions.py
totyping_extensions_1.py
.
Yes, that's because when you import typing_extensions
it's resolving to the typing_extensions
in typeshed. When you give it a unique name we don't find a match in typeshed and find the unique name in step 6 of the import resolution order -- https://microsoft.github.io/pyright/#/import-resolution?id=resolution-order
Somehow this step is being skipped for
typing_extensions
.
It's not skipped really. We never get there. We found typing_extensions
in typeshed in step 5 which takes priority over step 6.
Move
typing_extensions.py
into your virtual environment.I don't think that will make a difference, I'm getting this error if
typing_extensions
isn't globally installed.
Hmmm, it worked for me and I don't have typing_extensions
installed globally. The point of this would be that our import resolver would find it in your venv before looking in typeshed.
Shouldn't it only report shadowed imports if it can't find the imported symbol, but it's present in the shadowed module?
The shadowed import diagnostic is not about a symbol, but rather a module -- in these scenarios it's warning that your local typing_extensions
is resolving instead of the pyi from stdlib.
Use a relative import
That won't work, as the libraries can be optionally installed.
What happens when it's not installed? If you don't have typing_extensions.py
in the local directory, do you want to fall back to some other copy? The one in your venv?
We never get there.
If it can't resolve the module, it should move on the step 6:
if all of the above attempts fail, attempt to import a module from the same directory
Hmmm, it worked for me
root/venv/src/typing_extensions.py
is still not found.
What happens when it's not installed?
It will be better to explain with an example: https://github.com/nineteendo/pyvz2/tree/alpha
pyvz2-alpha
+-src
|-jsonyx
|-__main__.py
+-typing_extensions.py
If you download this repository you can run the jsonyx
tool directly with python src json
.
If you want to use the C accelerators or use the module in your own scripts, you can install it with pip install src/
.
Here's the thing: if I don't include typing_extensions.py
in src/
, you HAVE to use a venv or install it globally.
You won't be able to run it directly.
So, this means that I freeze typing_extensions
to a specific version in my project, but not when used elsewhere after installation.
If it can't resolve the module, it should move on the step 6:
Yes, but it did resolve the module. It found it in Pylance's bundled copy of typeshed.
root/venv/src/typing_extensions.py
is still not found.
It needs to be under site-packages
.
I'll try your repo later today.
The typing_extensions
module is a special case because it's included in the typeshed "stdlib" stubs but is not actually part of stdlib.
I'm not that familiar with the code in pyright that tracks "shadowed" modules (i.e. ".py" files that correspond to ".pyi" files). This functionality was added by the pylance team (along with the reportMissingModuleSource
check) and isn't used by the core type checking functionality. Perhaps the shadowing logic is making incorrect assumptions about "typing_extensions" based on the fact that it's part of typeshed's stdlib stubs?
Yeah, I think that's exactly what's happening. That also explains why it gives this error if I open the worktree directly:
"/Users/wannes/Library/CloudStorage/OneDrive-Personal/Personal/GitHub/pyvz2/alpha/src/typing_extensions.py" is overriding the STDLIB module "typing_extensions"
So, that error message is not even correct.
Changing the shadowed import diagnostic behavior isn't going to change how the import is resolved though. Are you saying that one of the alternatives I listed above would work for you, except for the diagnostic? If that's the case, while we consider whether to change the diagnostic's behavior with typing_extensions
you could disable the diagnostic?
It's fine to resolve to the stub file, but isn't there a second kind of resolving going on:
Import "typing_extensions" could not be resolved from source
Right now I'm suppressing the error with type: ignore
.
It's fine to resolve to the stub file, but isn't there a second kind of resolving going on:
Yes, we do a separate resolution to look for the source file, and in this case we don't do step 6 in the resolution order that we were discussing above.
I agree that this is a bug, but it's not clear to me that it impacts a large number of users. Wanting to match a library/built-in stub with a user source file seems unusual. Without feedback from more users indicating that this is problematic, it's unlikely that we will prioritize fixing it.
Therefore, I'm inclined to treat this as an enhancement and move it to discussions to see if other users up-vote it.
Right now I'm suppressing the error with type: ignore.
Note that you can suppress the reportMissingModuleSource
diagnostic globally in a pyrightconfig.json
file (see sample here) or your VS Code settings (python.analysis.diagnosticSeverityOverrides
).
Environment data
Code Snippet
repo/main/src/typing_extensions.py
: typing_extensionse239100
Directory tree
Expected behavior
No warnings, I'm bundling a version of the third-party
typing_extensions
module, not a module from the stdlib.Actual behavior
Logs