Skip to content

Fix imports in __init__.py files to explicitly re-export symbols #891

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

lukaspiatkowski
Copy link

Requirements for Contributing to this repository

  • Fill out the template below. Any pull request that does not include enough information to be reviewed in a timely manner may be closed at the maintainers' discretion.
  • The pull request must only fix one issue, or add one feature, at the time.
  • The pull request must update the test suite to demonstrate the changed functionality.
  • After you create the pull request, all status checks must be pass before a maintainer reviews your contribution. For more details, please see CONTRIBUTING.

What does this PR do?

Fixes #842.
By default imports in __init__.py files are treated by type checkers (like mypy or pyright) as private.
With this PR type checkers start to recognize selected symbols imported in __init__.py files as re-exported, so that code like this:

from datadog import statsd

is no longer treated as importing private implementation details of the library.

Description of the Change

In order to mark symbols as intended to be re-exported you can use one of the special import forms. This change does that by adding from Y import X as X (a redundant symbol alias) as described in official Import Conventions written by The Python Typing Team.

Alternate Designs

As an alternative one might define the __all__ module-level attribute in __init__.py file that lists all the symbols intended to be re-exported. The symbols listed in __all__ are represented by str. Making sure that this is list up-to-date might become problematic as only type checkers use that information and not every IDE supports recognizing those strings as symbols, making it hard to maintain them.

Possible Drawbacks

One have to remember to keep those re-export up-to-date to keep type checkers happy.

Verification Process

I've checked by running pyright on

from datadog import statsd

if it gives a warning reportPrivateImportUsage.

Additional Notes

Release Notes

Review checklist (to be filled by reviewers)

  • Feature or bug fix MUST have appropriate tests (unit, integration, etc...)
  • PR title must be written as a CHANGELOG entry (see why)
  • Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
  • PR must have one changelog/ label attached. If applicable it should have the backward-incompatible label attached.
  • PR should not have do-not-merge/ label attached.
  • If Applicable, issue must have kind/ and severity/ labels attached at least.

By default imports in __init__.py files are treated by type checkers as
private. In order to re-export them one have to either list them in
__all__ module-level attribute or use one of the special import forms.
@lukaspiatkowski lukaspiatkowski requested review from a team as code owners February 21, 2025 08:56
Copy link

This issue has been automatically marked as stale because it has not had activity in the last 30 days.
Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity.

@github-actions github-actions bot added the stale Stale - Bot reminder label Mar 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stale Stale - Bot reminder
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mypy error: Module "datadog" does not explicitly export attribute "statsd" [attr-defined]
1 participant