Support code completion for modules imported with alias.

[tillahoffmann]

It would be nice to support code completion for modules that are not auto-imported by the parent package when the parent package is aliased. Bit of a mouthful. Here's an example.

import scipy
import scipy.stats  # scipy.stats is not auto-imported by scipy.
import scipy as sc

scipy.stats.  # Opens code completion.
sc.stats.  # Does not open code completion.

Code completion works as expected when the parent package auto-imports the module. Another example.

import numpy as np  # numpy.fft is auto-imported by numpy.

np.fft.  # Opens code completion.

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[erictraut]

This usage relies on implicit side effects of an import statement, so it's a bit of an anti-pattern — one that can lead to code fragility and bugs. As such, I would recommend against using this practice.

In Python, an import statement has a set of defined (explicit) side effects, but it also unfortunately has a set of implicit side effects, such as caching imported submodules. It is a common source of fragility and bugs in Python to rely on these temporal side effects. Pyright (the static type analyzer that underlies Pylance) intentionally does not model these implicit side effects in its analysis. In practice, it's not possible to fully model these effects because they depend on dynamic (runtime) ordering of module loading, and that cannot be predicted statically. Within a single file, it is theoretically possible to model implicit side effects, but relying on these is still not recommended. In your case, you are relying on the fact that the import scipy.stats statement happens to populate the stats field within the module pointed to by the local symbol sc.

Our general philosophy for completion suggestions is that we don't include recommendations that lead to code fragility or bugs. Since this isn't a pattern we would generally recommend, I don't think it would be prudent for us to add support for it in the completion provider. My recommendation is that you avoid relying on implicit import side effects within your code and move away from this pattern.

[tillahoffmann]

Agreed that only using explicit imports is, well, more explicit. Having said that, I would argue that this pattern does not rely on implicit side effects. E.g. consider the following two imports.

import scipy
import scipy as sp
scipy is sp  # True

scipy and sp are one and the same thing, and I'd expect code completion to work on either (given that they're the same). Furthermore, the following code snippet works as expected.

import scipy
import scipy.stats

sp = scipy
sp.stats.  # Opens code completion.

It seems that the functionality is already available but not enabled for aliased imports.

Another aspect to consider may be the de facto widespread use of the pattern. E.g. searching github for "import scipy as sp" AND "sp.stats" yields over 1k results. This is of course a lower bound because of the specificity of the query. Other common includes also yield a large number of hits:

"import scipy as sp" AND ...

• sp.sparse: >5k
• sp.linalg: >4k
• sp.optimize: >1k

I'd expect similar patterns to be common in (the use of) libraries that have expensive imports, e.g. matplotlib, tensorflow, and pytorch.

Thanks for the great python-vscode integration and the feedback!