Skip to content

Implicit re-exports should not be disabled for installed PEP 561 packages #8754

Closed
Closed
Implicit re-exports should not be disabled for installed PEP 561 packages#8754
Labels
bugmypy got something wrongfalse-positivemypy gave an error on correct codepriority-1-normaltopic-pep-561

Description

@GPHemsley
GPHemsley
opened on May 1, 2020

With:

  • Python 3.6.10
  • mypy 0.770
  • requests 2.23.0
  • tenacity 6.2.0

the following code:

#!/usr/bin/env python3

from typing import (
	Any,
	Callable,
)

import requests
import tenacity

# Keep trying the request until we connect.
@tenacity.retry(retry=tenacity.retry_if_exception_type(requests.exceptions.ConnectionError))
def retry_if_connection_error(func: Callable[..., requests.Response], *args: Any, **kwargs: Any) -> requests.Response:
	return func(*args, **kwargs)

# Keep trying the request unless we connect.
@tenacity.retry(retry=tenacity.retry_unless_exception_type(requests.exceptions.ConnectionError))
def retry_unless_connection_error(func: Callable[..., requests.Response], *args: Any, **kwargs: Any) -> requests.Response:
	return func(*args, **kwargs)

produces the following output:

$ mypy --strict scripts/dev_test_mypy_tenacity.py
scripts/dev_test_mypy_tenacity.py:12: error: Module has no attribute "retry_if_exception_type"; maybe "retry_if_exception", "retry_unless_exception_type", or "retry_if_exception_message"?
    @tenacity.retry(retry=tenacity.retry_if_exception_type(requests.exceptions.ConnectionError))
                          ^
scripts/dev_test_mypy_tenacity.py:17: error: Module has no attribute "retry_unless_exception_type"; maybe "retry_if_exception_type"?
    @tenacity.retry(retry=tenacity.retry_unless_exception_type(requests.exceptions.ConnectionError))
                          ^
Found 2 errors in 1 file (checked 1 source file)

Note that each error message suggests an alternative that the other error message insists does not exist.

Tenacity only just added the bare minimum of type hints (jd/tenacity#221), so I don't know if there's some conflict there, but even if that's the case, this seems like a bug in mypy.

Possibly related mypy issues: #8220, #8210, #7125, #7029, #6551, #4930

Activity

  1. JukkaL commented on May 1, 2020

    @JukkaL
    JukkaL
    on May 1, 2020
    Collaborator

    This seems to be caused by --no-implicit-reexport. Implicit re-exports should always be allowed in PEP 561 packages, but that's not the case right now.

    As a workaround, you can run mypy with --strict --implicit-reexport.

  2. JukkaL
    changed the title [-]mypy reports missing module attribute that it knows is there[/-] [+]Implicit re-exports should not be disabled for installed PEP 561 packages[/+] on May 1, 2020
  3. JukkaL
    added
    bugmypy got something wrong
    false-positivemypy gave an error on correct code
    priority-1-normal
    topic-pep-561
    on May 1, 2020
  4. peterfpeterson
    added 2 commits that reference this issue on Jun 1, 2020

    Ignore typing errors associated with module layout

    7850e3e

    Ignore typing errors associated with module layout

    36f6604

  5. hauntsaninja commented on Aug 7, 2020

    @hauntsaninja
    hauntsaninja
    on Aug 7, 2020
    Collaborator

    Note that #9237 should improve the error message here

  6. pyoor
    added 2 commits that reference this issue on Jun 24, 2021

    fix: disable mypy implicit-reexport checking

    2545186

    feat: enable mypy type checking (#44)

    bb3ed92

  7. gaborbernat commented on Aug 2, 2021

    @gaborbernat
    gaborbernat
    on Aug 2, 2021
    Contributor

    Implicit re-exports should always be allowed in PEP 561 packages, but that's not the case right now.

    How come @JukkaL? I think implicit re-export should be an opt-in, not always-on feature. I could imagine py.typed file containing some flag to enable/disable this.

  8. erictraut commented on Aug 2, 2021

    @erictraut
    erictraut
    on Aug 2, 2021

    Implicit re-exports should always be allowed in PEP 561 packages, but that's not the case right now.

    This contradicts what (I thought) we had agreed to in the typing-sig discussion on this topic. If a package claims to be py.typed, then it needs to follow typing rules and be explicit about what symbols are exported from each submodule. Pyright assumes that py.typed packages never use implicit re-exports. Here is the guidance we have been providing to package authors, and pyright's implementation is consistent with this guidance. I would encourage mypy to default to the same behavior to provide consistency for package authors.

  9. Jeremiah-England
    added a commit that references this issue on Sep 4, 2023

    chore: Export intended public imports

    b753e82
  10. ErikBjare
    added a commit that references this issue on Sep 4, 2023

    chore: export intended public imports in __all__ (#76)

    2517cb1

  11. hauntsaninja commented on Nov 12, 2023

    @hauntsaninja
    hauntsaninja
    on Nov 12, 2023
    Collaborator

    Between #9237 / #13925 / #13967 / #16129 I think we've done everything I'd want to do here

  12. hauntsaninja
    closed this as completedon Nov 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugmypy got something wrongfalse-positivemypy gave an error on correct codepriority-1-normaltopic-pep-561

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions