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

`stubgen --recursive` stubs entire package even when only subpackage was requested. #4844

mgilson opened this Issue Apr 3, 2018 · 1 comment


None yet
2 participants
Copy link

mgilson commented Apr 3, 2018

This is a request for a slight change of behavior for stubgen. Right now, if I use stubgen --recursive urllib.parse, stubs will be generated for the entirety of urllib.

$ stubgen --recursive urllib.parse
Created out/urllib/__init__.pyi
Created out/urllib/error.pyi
Created out/urllib/parse.pyi
Created out/urllib/request.pyi
Created out/urllib/response.pyi
Created out/urllib/robotparser.pyi

This seems to be somewhat odd behavior -- I would have expected stubgen to only generate out/urllib/parse.pyi. To generate all the stubs, I would expect stubgen --recursive urllib (currently there is no difference between passing urllib.parse and urllib as the module to be stubbed).

The behavior is because of the use of __import__ rather than importlib.import_module in walk_packages.

I'm not completely sure if this is an intended feature or a bug, but I figured that I'd report it and find out.


This comment has been minimized.

Copy link

gvanrossum commented Apr 3, 2018

That looks like nobody really tested this before. I agree that it's odd behavior. Do you want to try sending a PR to fix it?

mgilson pushed a commit to mgilson/mypy that referenced this issue Apr 3, 2018

gvanrossum added a commit that referenced this issue Apr 3, 2018

Fix stubgen --recursive to only generate stubs for requested submodul…
…es. (#4845)

This fixes #4844

This also adds a place to do unit-testing on other utility functions for the stubgen CLI.

The general idea here is to test `walk_packages` against `mypy` itself since (presumably) is is already imported or will be imported during the tests.  We should also know the exact module structure (unlike something like `urllib` that changes depending on python2.x and python3.x).  I tried not to make the test too prescriptive to reduce the chances that it will need to be updated when new modules or subpackages are added to `mypy`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.