Ability to match a library/built-in stub with a user source file #6516
Replies: 11 comments
-
|
@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:
|
Beta Was this translation helpful? Give feedback.
-
Note that it doesn't complain if I rename
Somehow this step is being skipped for
That won't work, as the libraries can be optionally installed.
I don't think that will make a difference, I'm getting this error if
It's very convenient to have the different branches of the repository as subfolders (work trees) of the workspace root. Shouldn't it only report shadowed imports if it can't find the imported symbol, but it's present in the shadowed module? |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to write |
Beta Was this translation helpful? Give feedback.
-
Yes, that's because when you import
It's not skipped really. We never get there. We found
Hmmm, it worked for me and I don't have
The shadowed import diagnostic is not about a symbol, but rather a module -- in these scenarios it's warning that your local
What happens when it's not installed? If you don't have |
Beta Was this translation helpful? Give feedback.
-
If it can't resolve the module, it should move on the step 6:
It will be better to explain with an example: https://github.com/nineteendo/pyvz2/tree/alpha If you download this repository you can run the Here's the thing: if I don't include So, this means that I freeze |
Beta Was this translation helpful? Give feedback.
-
Yes, but it did resolve the module. It found it in Pylance's bundled copy of typeshed.
It needs to be under I'll try your repo later today. |
Beta Was this translation helpful? Give feedback.
-
|
The 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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
It's fine to resolve to the stub file, but isn't there a second kind of resolving going on:
Right now I'm suppressing the error with |
Beta Was this translation helpful? Give feedback.
-
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.
Note that you can suppress the |
Beta Was this translation helpful? Give feedback.
-
Environment data
Code Snippet
repo/main/src/typing_extensions.py: typing_extensionse239100Directory tree
Expected behavior
No warnings, I'm bundling a version of the third-party
typing_extensionsmodule, not a module from the stdlib.Actual behavior
Logs
Beta Was this translation helpful? Give feedback.
All reactions