The indexer's implementation of import * uses different semantics from all the other forms of import. It's basically a bug, although the jury is still out as to which implementation is better.
For the others we define name bindings anywhere an actual name is introduced into the scope containing the import statement, and references to the imported module or name everywhere else. This mimics the behavior of Python at runtime, but it may be confusing to anyone with only a casual understanding of Python's data model, who might think it works more like Java.
For import * we just enter the imported names into the symbol table, which lets other code reference them, but the references "pass through" automatically to the module from which the names were imported.
To illustate the difference, consider the following four modules:
moduleA.py: a = 1 b = 2 moduleB.py: c = 3 d = 4 moduleC.py: from moduleA import a, b from moduleB import print a # indexer finds definition of 'a' 2 lines up print b # indexer finds definition of 'b' 3 lines up print c # indexer finds definition of 'c' in moduleB print d # indexer finds definition of 'd' in moduleB moduleD.py: import moduleC print moduleC.a # indexer finds definition of 'a' in moduleC print moduleC.b # indexer finds definition of 'b' in moduleC print moduleC.c # indexer finds definition of 'c' in moduleB print moduleC.c # indexer finds definition of 'd' in moduleBTo make import * work like the others, we need only create bindings for the imported names. But where would the bindings be located? Assuming that we were to co-locate them all at the "*" name node, clicking on a reference to any of the names would jump to the "*". It's not clear that this is a better user experience.
We could make the other import statement forms work like {@code import *}, but that path is even more fraught with confusing inconsistencies.
| |
| |