-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
torch.tensor type annotation does not match mypy #545
Comments
What version of pytorch are you using? Is it the stable version or the release candidate? There are a couple of odd typing issues with both (#418, #484) that could be in play here. I believe this would involve the code that does the assignments for module exports; I recall previous bugs in this area (but can't find them). Perhaps this is happening because @erictraut Do you have any thoughts? |
I'd need to understand what version of pytorch is being used. I'm not seeing this with the version I'm using. Based on the symptoms, it appears that the symbol |
I'm on 1.7.0, which is the latest stable version available on PyPI. |
Thanks; I hadn't seen that 1.7 was out yet.
See #545 (comment) |
Yeah, that would explain it if the original definition of |
I dug into this and found that we were handling the following cases inconsistently:
In the first case, the type evaluator was considering all declarations in the target module and unioning their types. In the second case, the type evaluator was using only the last declaration found within the file. I've updated the logic to consistently use only the last declaration, which produces the desired behavior. This change will be in the next release. In the meantime, you can use the |
Thank you for taking care of this! |
This issue has been fixed in version 2020.11.0, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/master/CHANGELOG.md#2020110-4-november-2020 |
For anyone experiencing this problem with torch tensors, a way for mypy to pass is to type annotate as my_tensor: torch.Tensor = func_returning_tensor([1,2,3]) Notice that it is |
Environment data
Expected behaviour
Consider the following:
I expect Pylance to infer that
torch.tensor
symbol is referring only to thetorch.tensor(...)
callable, as mypy does, and not the union of the callable and thetorch/tensor.py
module.Here's what I think it should be.
mypy
Pylance
Actual behaviour
Here's what the inferred types are right now.
mypy
Pylance
Logs
If logs are helpful here, I can include them. I do not think they're super helpful here, though.
Code Snippet / Additional information
I know it's not ideal that there's a name conflict in the PyTorch codebase between the
torch.tensor(...)
callable and thetorch.tensor
module, but mypy appears to get the right idea, so there's a way to deduce this somehow.I can get Pylance to narrow the type definition with an
assert
statement, as in the following.I also can throw a
# type: ignore
comment everywhere to silence Pylance but then the return type oftorch.tensor(...)
is marked asUnknown
instead of beingtorch.Tensor
, which is very useful to have inferred.Thank you!
The text was updated successfully, but these errors were encountered: