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

Package not re-exporting symbols in package __init__.py #1547

Closed
tjohanssonn opened this issue Mar 24, 2023 · 4 comments · Fixed by #1551
Closed

Package not re-exporting symbols in package __init__.py #1547

tjohanssonn opened this issue Mar 24, 2023 · 4 comments · Fixed by #1551

Comments

@tjohanssonn
Copy link

Describe the bug

python-can is not re-exporting symbols correctly. This causes Pylance to not provide Intellisense when using e.g. Bus class, and also warns about usage of private import:

"Bus" is not exported from module "can" Pylance[reportPrivateImportUsage]

Link to webpage: reportPrivateImportUsage

To Reproduce

  1. Editor: Visual Studio Code
  2. Language server: Pylance
  3. Set configuration "python.analysis.typeCheckingMode": "basic"
  4. Minimum code example:
import can

bus = can.Bus(bustype='socketcan', channel='vcan0', bitrate=500000)

Expected behavior

Symbols imported in package/init.py should be publicly available, and not trigger a private import usage warning.

For more context on Pylance stance on this issue, see e.g. microsoft/pylance-release#2953 (comment)

Additional context

OS and version: Windows 10 22H2 OS build 19045.2728
Python version: 3.10.2
python-can version: 4.1.0
python-can interface/s (if applicable):

Screenshot of warning(s)

image

@felixdivo
Copy link
Collaborator

Interesting, that this did not come up earlier. Would setting __all__ solve this?

It seems to me like we probably want that attribute anyways.

@zariiii9003
Copy link
Collaborator

Interesting, that this did not come up earlier. Would setting __all__ solve this?

It seems to me like we probably want that attribute anyways.

I'd prefer the import x as x method. With __all__ you would always need to make changes in two places.

@felixdivo
Copy link
Collaborator

I see that, but by adding the __all__, we'd kill two birds with one stone: Pleasing the type cheker + making from can import * do something more controlled.

@tjohanssonn
Copy link
Author

Tested branch and it seems to be working, thank you for the fix 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants