Stub generation and module re-exports, #noqa

Open
#2,190 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
python
Domain
tooling

Research direction

Start by locating stubgen's handling of wildcard and explicit imports, then review any existing tests for generated re-exports. The issue presents three unresolved policy options, so agree on the intended behavior first. Done means the chosen policy is implemented and covered by a regression test for explicit re-exports such as the Django example.

Written by the indexing model from the issue text.

Description

priority-2-low topic-stubgen

Many larger libraries break up their packages into multiple modules, then "re-export" the modules in the package's __init__.py

For example, in django.db.models:

from django.db.models.fields import *  # NOQA
from django.db.models.fields.files import FileField, ImageField  # NOQA

This allows you to import FileField and CharField (from django.db.models.fields) directly from django.db.models

stubgen currently provides these re-exports in the case of import *, but not in the second import. So FileField is missing from the django.db.models stub.

This makes sense, since all imports are re-exports, but that might not be the wanted API (should I really be importing requests from some random module in the middle of my application? probably not). But, of course, sometimes it's on purpose.

This does come up a lot, though, so I was thinking of 3 possible solutions:

  • Re-export all imports when doing stub generation
    This will cause generated stubs to best represent reality. This solution will make initial annotations easier, but also makes the output messier than what authors might want their public API to look like.
  • Re-export "unused" imports.
    This is tricky because intent is hard to decipher. In django's case, unused imports (with # noqa) are almost certainly meant for re-exporting. We could look for such comments on import lines, or figure out some other kind of heuristic.
  • Do nothing
    This issue comes up with big libraries, but not so much in application code. Big libraries usually have enough people to power through this sort of thing.

I tried looking in the issues and didn't see this coming up, but the easier the stub generation output is, the more likely people will get the third party annotation work done, so it would be cool to get this right. I think the second one is reasonable, first one is the easiest to implement.

Dominant language
Python
Stars
20.6k
Forks
3.3k
Avg merge
1d 18h
Merged PRs (30d)
54

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python/mypy

All issues in python/mypy

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.