Skip to content
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

"Parameter" is not exported from module "torch.nn" #2953

Closed
Yura52 opened this issue Jun 19, 2022 · 9 comments
Closed

"Parameter" is not exported from module "torch.nn" #2953

Yura52 opened this issue Jun 19, 2022 · 9 comments
Assignees
Labels
needs investigation Could be an issue - needs investigation reference

Comments

@Yura52
Copy link

Yura52 commented Jun 19, 2022

Environment data

  • macOS: 11.6
  • VSCode: 1.68.1
  • Pylance: v2022.6.20

I am working on this repository. So, my environment can be reproduced as follows:

# you can use conda instead of micromamba, the result is the same
micromamba create -n rtdl python=3.7
micromamba activate rtdl
pip install numpy=1.18.5 torch=1.7.1 scikit-learn=1.0.2
pip install -r requirements_dev.txt

Code Snippet

Create a file rtdl/a.py with the following content:

import torch.nn as nn

nn.Parameter

Expected behavior

I expect no warnings and no red underlines regarding nn.Parameter. mypy agrees with me and does not complain about this file.

Actual behavior

The nn.Parameter is underlined in red. Interestingly, when I hover over it, I see the correctly inferred docstring, but in the end at also contains the following error message: "Parameter" is not exported from module "torch.nn" Pylance (reportPrivateImportUsage)"

Logs

The logs are going beyond the GitHub limits :( If they are needed, what are the relevant parts that I should provide?

@Yura52
Copy link
Author

Yura52 commented Jun 19, 2022

I have just checked that the issue can be reproduced with the latest torch as well (1.11.0).

@judej judej added the needs investigation Could be an issue - needs investigation label Jun 20, 2022
@github-actions github-actions bot removed the triage label Jun 20, 2022
@bschnurr
Copy link
Member

bschnurr commented Jun 20, 2022

torch==1.11.0 worked for me on windows with python 3.10
i'll try linux

@Yura52
Copy link
Author

Yura52 commented Jun 20, 2022

Just in case, here is the illustration:

Screenshot 2022-06-19 at 16 57 29

@bschnurr
Copy link
Member

couldn't repro on linux. any luck on your side?

@linminhtoo
Copy link

linminhtoo commented Jun 28, 2022

I get the same error as well.

  error: "Parameter" is not exported from module "torch.nn" (reportPrivateImportUsage) 

I'm on nixos

Python 3.9.12 (main, Mar 23 2022, 21:36:19) 
[GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
>>> torch.__version__
'1.11.0+cu113'

@Yura52
Copy link
Author

Yura52 commented Jun 28, 2022

couldn't repro on linux. any luck on your side?

nope, and in fact I have been experiencing this issue for a long time

@erictraut
Copy link
Contributor

Torch is a "py.typed" library which means it contains inlined type information.

When a library is marked "py.typed", pyright (the type checker that underlies pylance) applies certain rules to determine whether specific symbols are intended to be visible from a module. These rules are documented here.

The module torch/nn/__init__.py imports the Parameter symbol, but it does not indicate that this symbol should be re-exported — and therefore made visible externally. To do so, it would need to use a redundant form of import: from .parameter import Parameter as Parameter. If you manually make that change in the torch/nn/__init__.py file, you'll see that nn.Parameter no longer generates an error.

If you believe that Parameter is meant to be visible from the torch.nn module, then this is a bug in the torch library, and you should report it to the torch maintainers.

As a workaround, you can access the Parameter symbol through the module that defines it: nn.parameter.Parameter.

You can also configure pylance to disable the reportPrivateImportUsage diagnostic rule, effectively silencing this error.

@Yura52
Copy link
Author

Yura52 commented Jun 28, 2022

Thank you for the detailed answer! I created the issue in the PyTorch repository.

P.S. Is the approach from .parameter import Parameter as Parameter expected to declare public interface by convention in Python or is it just a Pylance-specific workaround? To me it looks like the "portable" solution would be to explicitly create the __all__ variable.

@erictraut
Copy link
Contributor

This approach was standardized in PEP 484 for type stubs. It hasn't been officially adopted in a PEP for "py.typed" libraries, but there is general consensus among type checker authors that it makes sense to use the pattern established by PEP 484. This guidance has been posted on the python/typing site.

The __all__ variable designates "symbols that should be imported by a wildcard import", so it often overlaps with the notion of "symbols that are meant to be publicly visible from a module", but there are cases where the former is a subset of the latter.

@debonte debonte closed this as completed Jun 28, 2022
martinvonk added a commit to martinvonk/pedon that referenced this issue Mar 23, 2023
pytorchmergebot pushed a commit to pytorch/pytorch that referenced this issue Sep 28, 2023
Related: https://github.com/pytorch/pytorch/wiki/Public-API-definition-and-documentation
Related: microsoft/pylance-release#2953

This fixes pylance issues for these classes:

```
"FullyShardedDataParallel" is not exported from module "torch.distributed.fsdp"
```

These classes all have public docs:

* [`BackwardPrefetch`](https://pytorch.org/docs/stable/fsdp.html#torch.distributed.fsdp.BackwardPrefetch)
* [`CPUOffload`](https://pytorch.org/docs/stable/fsdp.html#torch.distributed.fsdp.CPUOffload)
* [`FullyShardedDataParallel`](https://pytorch.org/docs/stable/fsdp.html#torch.distributed.fsdp.FullyShardedDataParallel)
* [`MixedPrecision`](https://pytorch.org/docs/stable/fsdp.html#torch.distributed.fsdp.MixedPrecision)
* [`ShardingStrategy`](https://pytorch.org/docs/stable/fsdp.html#torch.distributed.fsdp.ShardingStrategy)

And it seems like all the newly added classes will have docs once they are released.

Pull Request resolved: #109922
Approved by: https://github.com/wanchaol
holocronweaver added a commit to holocronweaver/aws-error-utils that referenced this issue Nov 8, 2023
Python type checker libraries such as Pyrite have built a consensus around PEP 484 for how to export
symbols from a py.typed library. This requires redundantly re-exporting symbols
to make them publicly visible.

Without re-exporting the symbol type checkers will
complain that the symbol  (e.g., from aws_error_utils.errors) is not exported,
but a direct import will work as expected (e.g., from aws_error_utils.aws_error_utils
import errors).

Based on official Python guidance to type checkers: https://github.com/python/typing/blob/master/docs/source/libraries.rst#library-interface-public-and-private-symbols

For more detail from author of Pyrite (for a similar issue in PyTorch):
microsoft/pylance-release#2953 (comment)
holocronweaver added a commit to holocronweaver/aws-error-utils that referenced this issue Nov 11, 2023
Python type checker libraries such as Pyright have built a consensus around PEP 484 for how to export
symbols from a py.typed library. This requires redundantly re-exporting symbols
to make them publicly visible.

Without re-exporting the symbol type checkers will
complain that the symbol  (e.g., from aws_error_utils.errors) is not exported,
but a direct import will work as expected (e.g., from aws_error_utils.aws_error_utils
import errors).

Based on official Python guidance to type checkers: https://github.com/python/typing/blob/master/docs/source/libraries.rst#library-interface-public-and-private-symbols

For more detail from author of Pyright (for a similar issue in PyTorch):
microsoft/pylance-release#2953 (comment)
pytorchmergebot pushed a commit to pytorch/pytorch that referenced this issue Sep 4, 2024
pytorchmergebot pushed a commit to mori360/pytorch that referenced this issue Sep 5, 2024
tolleybot pushed a commit to tolleybot/pytorch that referenced this issue Sep 14, 2024
Chao1Han pushed a commit to Chao1Han/pytorch that referenced this issue Sep 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs investigation Could be an issue - needs investigation reference
Projects
None yet
Development

No branches or pull requests

6 participants