stubgen: fix package imports with aliases - #9534
Conversation
96009e7 to
c228073
Compare
importing multiple packages using aliases (import p.a as a) did not work correctly.
c228073 to
5e7f945
Compare
|
|
||
| [out] | ||
| import FIXME as cookielib | ||
| import cookielib as cookielib |
There was a problem hiding this comment.
for reference, here is the complete test:
[case testConditionalImportAll_semanal]
__all__ = ['cookielib']
if object():
from http import cookiejar as cookielib
else:
import cookielib
[out]
import cookielib as cookielib
hauntsaninja
left a comment
There was a problem hiding this comment.
Thanks for finding and fixing this! Despite the review request, this is actually my first time really looking at stubgen code...
Anyway, this looks good to me. Your (very thorough) test cases all check out and the changes make sense.
I was a little bit worried about the FIXME test case that needed changing... On first read, I thought it was intended as a feature for stubgen to highlight conditional imports with a FIXME. But it looks like that isn't what's happening here, since we're happy enough to clobber reverse_alias. I.e., the change in behaviour here seems consistent with things stubgen does in other places.
I'll leave open for a day or two, just in case someone else who's worked with stubgen more has something to say.
Description
Running
stubgenon modules that import multiple packages using aliases did not produce the correct results:Input:
Result:
Test Plan
I added a bunch of new tests to stubgen.test.
I had to change one of the expected results:
testConditionalImportAll_semanal. Previously, if more than one module import introduced the same name into the namespace, the data structures used to track imports were simply allowed to become corrupted, and the generator would produceimport FIXME as whatever. After correcting the internal state to fix the issue that prompted this PR, I realized it would be difficult to maintain the current output for this test, so I chose to change the behavior. I went with what I think is a sane solution: if multiple import statements target the same name, rather than produce invalid output, use the last import encountered. The last import would be the one used at runtime. I also considered using the first import, since this is what mypy would use.