Python difference between 'import as' vs variable assignment

Question

How do the following two statements differ and what are the consequences of each?

Import as:

from module.submodule import someclass as myclass

Assign to a variable:

from module.submodule import someclass
myclass = someclass

Answer 1

The bytecode output given here is for Python 3.4, but the code to produce the bytecode should work on any version and the same general principles apply.

Harness:

from dis import dis

def compile_and_dis(src):
    dis(compile(src, '<string>', 'exec'))

Case 1:

>>> compile_and_dis('from module.submodule import someclass as myclass')
  1           0 LOAD_CONST               0 (0)
              3 LOAD_CONST               1 (('someclass',))
              6 IMPORT_NAME              0 (module.submodule)
              9 IMPORT_FROM              1 (someclass)
             12 STORE_NAME               2 (myclass)
             15 POP_TOP
             16 LOAD_CONST               2 (None)
             19 RETURN_VALUE

This is the only approach that only adds one name (myclass) into the current locals() (i.e. __dict__, which will become globals() for everything defined in the module). It is also the shortest bytecode.

This method will raise ImportError if someclass is not found in module.submodule. It will, however, attempt to load module.submodule.someclass as a module.

Case 2:

>>> compile_and_dis('from module.submodule import someclass; myclass = someclass')
  1           0 LOAD_CONST               0 (0)
              3 LOAD_CONST               1 (('someclass',))
              6 IMPORT_NAME              0 (module.submodule)
              9 IMPORT_FROM              1 (someclass)
             12 STORE_NAME               1 (someclass)
             15 POP_TOP
             16 LOAD_NAME                1 (someclass)
             19 STORE_NAME               2 (myclass)
             22 LOAD_CONST               2 (None)
             25 RETURN_VALUE

This is nearly identical to case 1, except that it leaks a second name (someclass) into the local namespace. If the import and assignment are not contiguous, you do run the theoretical risk of reusing the name for something else, but if you're shadowing names you have horrible design anyway.

Note the useless STORE_NAME/LOAD_NAME cycle in the bytecode (around an unrelated POP_TOP).

Case 3:

>>> compile_and_dis('from module import submodule; myclass = submodule.someclass')
  1           0 LOAD_CONST               0 (0)
              3 LOAD_CONST               1 (('submodule',))
              6 IMPORT_NAME              0 (module)
              9 IMPORT_FROM              1 (submodule)
             12 STORE_NAME               1 (submodule)
             15 POP_TOP
             16 LOAD_NAME                1 (submodule)
             19 LOAD_ATTR                2 (someclass)
             22 STORE_NAME               3 (myclass)
             25 LOAD_CONST               2 (None)
             28 RETURN_VALUE

This approach leaks submodule into the local namespace. It does not raise ImportError if the class is not found, rather it raises AttributeError during the assignment. It does not attempt to load module.submodule.someclass as a module (and in fact doesn't even care whether or not module.submodule is a module).

Case 4:

>>> compile_and_dis('import module.submodule as submodule; myclass = submodule.someclass')
  1           0 LOAD_CONST               0 (0)
              3 LOAD_CONST               1 (None)
              6 IMPORT_NAME              0 (module.submodule)
              9 LOAD_ATTR                1 (submodule)
             12 STORE_NAME               1 (submodule)
             15 LOAD_NAME                1 (submodule)
             18 LOAD_ATTR                2 (someclass)
             21 STORE_NAME               3 (myclass)
             24 LOAD_CONST               1 (None)
             27 RETURN_VALUE

This is similar to case 3 but requires that module.submodule be a module.

Case 5:

>>> compile_and_dis('import module.submodule; myclass = module.submodule.someclass')
  1           0 LOAD_CONST               0 (0)
              3 LOAD_CONST               1 (None)
              6 IMPORT_NAME              0 (module.submodule)
              9 STORE_NAME               1 (module)
             12 LOAD_NAME                1 (module)
             15 LOAD_ATTR                2 (submodule)
             18 LOAD_ATTR                3 (someclass)
             21 STORE_NAME               4 (myclass)
             24 LOAD_CONST               1 (None)
             27 RETURN_VALUE

This approach is similar to case 4, although the 2 attribute loads are at different places so a different variable leaks into the local namespace.

Answer 2

The main difference is that in your variable assignment example, someclass is still available as a name. That'll lead to issues when importing types with the same name.

from datetime import datetime
from arrow import datetime  # problem!

To fix this:

from datetime import datetime
from arrow import datetime as arrow_datetime