Question

Python allows aliasing of imports, through ...as <ALIAS> clauses in the import statement, like this:

import mymodule as somealias
from myothermodule import spam as spamalias, ham as hamalias

Now, in the default case at least, import statements, including those that have as-clauses like the ones above, result in calls to __builtin__.__import__ whose arguments lists do not include the names of such aliases. IOW, AFAICT, the following “aliasing-free” import statements produce identical calls to __builtin__.__import__ as do the import statements quoted above:

import mymodule
from myothermodule import spam, ham

So how do these alias names enter the import process? And does Python provide ways to customize how alias names are used by the import process?

(I don’t have any specific application in mind; I’m just trying to better understand how Python works.)

Answer 1

The function __import__() does not bind any names in the calling scope. Basically,

import foo

is similar to

foo = __import__("foo")

and

import foo as bar

is similar to

bar = __import__("foo")

Name binding happens in the calling scope, not inside the function, so __import__() does not need to know what name the module will finally be bound to.

This can also be seen from the CPython byte code of these statements:

>>> dis.dis(compile("import foo", "", "exec"))
  1           0 LOAD_CONST               0 (-1)
              3 LOAD_CONST               1 (None)
              6 IMPORT_NAME              0 (foo)
              9 STORE_NAME               0 (foo)
             12 LOAD_CONST               1 (None)
             15 RETURN_VALUE        
>>> dis.dis(compile("import foo as bar", "", "exec"))
  1           0 LOAD_CONST               0 (-1)
              3 LOAD_CONST               1 (None)
              6 IMPORT_NAME              0 (foo)
              9 STORE_NAME               1 (bar)
             12 LOAD_CONST               1 (None)
             15 RETURN_VALUE        

The IMPORT_NAME opcode implicitly calls __import__() and leaves the resulting module on the internal stack. The subsequent STORE_NAME pops the module from the stack and binds it to a local name. You can see the only difference between the two snippets is which name the module gets stored to.