Skip to content

The behavior of --no-explicit-reexport is inconsistent/misleading #11706

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

Closed
pavel-kirienko opened this issue Dec 10, 2021 · 5 comments · Fixed by #11707
Closed

The behavior of --no-explicit-reexport is inconsistent/misleading #11706

pavel-kirienko opened this issue Dec 10, 2021 · 5 comments · Fixed by #11707
Labels
bug mypy got something wrong

Comments

@pavel-kirienko
Copy link

Bug Report

The behavior of --no-explicit-reexport is inconsistent/misleading, see MWE below.

To Reproduce

Define the following package of four files:

├── a
│   ├── __init__.py
│   └── X.py
├── c.py
└── d.py

a/__init__.py:

from a.X import X as X
Y = X

a/X.py

class X:
    pass

c.py

from a import Y as W

d.py

from c import W

Expected Behavior

$ mypy --strict --no-implicit-reexport .
Success: no issues found in 4 source files

Actual Behavior

$ mypy --strict --no-implicit-reexport .
d.py:1: error: Module "c" does not explicitly export attribute "W"; implicit reexport disabled
Found 1 error in 1 file (checked 4 source files)

The docs state that the form import ... as ... is sufficient to mark the imported item for re-export, so this is expected to work. However, the most suspicious part is that if you modify c.py (sic!) as follows:

-- from a import Y as W
++ from a import X as W

then MyPy reports no error.

One would expect both cases to be accepted.

Note that if a is not a package, both cases yield a re-export error.

Your Environment

  • Mypy version used: 0.910
  • Mypy command-line flags: --strict --no-implicit-reexport
  • Mypy configuration options from mypy.ini (and other config files): none
  • Python version used: 3.10
  • Operating system and version: GNU/Linux Manjaro 21.2
@pavel-kirienko pavel-kirienko added the bug mypy got something wrong label Dec 10, 2021
@hauntsaninja
Copy link
Collaborator

Thanks, can repro the inconsistency on master, the expected behaviour is an error in both cases. This was somewhat recently clarified in PEP 484 (https://github.com/python/peps/pull/1630/files)

@hauntsaninja
Copy link
Collaborator

I'd welcome a corresponding update to our docs, if you want to make a PR for it! :-)

pavel-kirienko added a commit to OpenCyphal/pycyphal that referenced this issue Dec 10, 2021
* application: remove unecessary dropped error msg (#186)

* socketcan: improve incorrect config error message

* transport: can: pythoncan: update can mtu heuristic to support slcan

* Fix #193

* Fix #192

* Bump the dependency versions

* Deprecate the loop property and constructor parameter

* Cover #146

* Fix #176

* Add Python 3.10

* Add a temporary workaround for Python 3.10 segfault during testing -- to be removed later when Python is fixed

* Rename installation extras to avoid warnings from pip

* Make SocketCAN test resilient against frame reordering

* Generate aliases for the newest minor version per major version

* Temporarily restrict Windows builds to Python 3.7 and 3.10 (oldest and newest) due to timeout issues

* Remove unnecessary minor version references from the application module

* MyPy: selectively enable explicit_reexport to work around this problem python/mypy#11706

Co-authored-by: Kalyan Sriram <[email protected]>
Co-authored-by: Kalyan Sriram <[email protected]>
@pavel-kirienko
Copy link
Author

Thanks, can repro the inconsistency on master, the expected behaviour is an error in both cases. This was somewhat recently clarified in PEP 484

This is a bit unexpected. What is the recommended pattern for re-exporting an entity under a different name? The following obvious approach looks verbose:

from x import y
z = y

@hauntsaninja
Copy link
Collaborator

Yup, that's what we used in typeshed :-)

@hauntsaninja
Copy link
Collaborator

Okay, I made #11707 to fix the inconsistency and it looks like #11083 updated the docs already

hauntsaninja added a commit that referenced this issue Dec 30, 2021
Fixes #11706

Co-authored-by: hauntsaninja <>
tushar-deepsource pushed a commit to DeepSourceCorp/mypy that referenced this issue Jan 20, 2022
JeppeKlitgaard added a commit to JeppeKlitgaard/jax that referenced this issue Apr 19, 2022
Explicitly reexports PRNGKeyArray as KeyArray in accordance with PEP 484

See also: python/mypy#11706
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug mypy got something wrong
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants