Mike Driscoll: Python 101: All about imports

One of the first items you learn as a beginner Python programmer is how to import other modules or packages. However, I’ve noticed that even people who have used Python casually for multiple years don’t always know how flexible Python’s importing infrastructure is. In this article, we will be looking at the following topics:

• Regular imports
• Using from
• Relative imports
• Optional imports
• Local imports
• import Pitfalls

Regular imports

A regular import, and quite possibly the most popular goes like this:

importsys

All you need to do is use the word “import” and then specify what module or package you want to actually import. The nice thing about import though is that it can also import multiple package at once:

importos, sys, time

While this is a space-saver, it’s goes against the Python Style Guide’s recommendations of putting each import on its own line.

Sometimes when you import a module, you want to rename it. Python supports this quite easily:

importsys as system
 
print(system.platform)

This piece of code simply renames our import to “system”. We can call all of the modules methods the same way before, but with the new name. There are also certain submodules that have to be imported using dot notation:

importurllib.error

You won’t see these very often, but they’re good to know about.

Using from module import something

There are many times when you just want to import part of a module or library. Let’s see how Python accomplishes this:

from functools import lru_cache

What the code above does is allow you to call lru_cache directly. If you had imported just functools the normal way, then you would have to call lru_cache using something like this:

functools.lru_cache(*args)

Depending on what you’re doing, the above might actually be a good thing. In complex code bases, it’s quite nice to know where something has been imported from. However, if your code is well maintained and modularized properly, importing just a portion from the module can be quite handy and more succinct.

Of course you can also use the from method to import everything, like so:

fromosimport*

This is handy in rare circumstances, but it can also really mess up your namespace. The problem is that you might define your own function or a top level variable that has the same name as one of the items you imported and if you try to use the one from the os module, it will use yours instead. So you end up with a rather confusing logic error. The Tkinter module is really the only one in the standard library that I’ve seen recommended to be imported in total.

If you happen to write your own module or package, some people recommend importing everything in your __init__.py to make your module or package easier to use. Personally I prefer explicit to implicit, but to each their own.

You can also meet somewhere in the middle by importing multiple items from a package:

fromosimport path, walk, unlink
fromosimport uname, remove

In the code above, we import five functions from the os module. You will also note that we can do so by importing from the same module multiple times. If you would rather, you can also use parentheses to import lots of items:

fromosimport(path, walk, unlink, uname, 
                remove, rename)

This is useful technique, but you can do it another way too:

fromosimport path, walk, unlink, uname, \
                remove, rename

The backslash you see above is Python’s line continuation character, which tells Python that this line of code continues on the following line.

Relative imports

PEP 328 describes how relative imports came about and what specific syntax was chosen. The idea behind it was to use periods to determine how to relatively import other packages / modules. The reason was to prevent the accidental shadowing of standard library modules. Let’s use the example folder structure that PEP 328 suggests and see if we can get it to work:

my_package/
    __init__.py
    subpackage1/
        __init__.py
        module_x.py
        module_y.py
    subpackage2/
        __init__.py
        module_z.py
    module_a.py

Create the files and folders above somewhere on your hard drive. In the top-level __init__.py, put the following code in place:

from . import subpackage1
from . import subpackage2

Next navigate down in subpackage1 and edit its __init__.py to have the following contents:

from . import module_x
from . import module_y

Now edit module_x.py such that is has the following code:

from .module_yimport spam as ham
 
def main():
    ham()

Finally edit module_y.py to match this:

def spam():
    print('spam '*3)

Open a terminal and cd to the folder that has my_package, but not into my_package. Run the Python interpreter in this folder. I’m using iPython below mainly because its auto-completion is so handy:

In [1]: import my_package
 
In [2]: my_package.subpackage1.module_x
Out[2]: <module 'my_package.subpackage1.module_x'from'my_package/subpackage1/module_x.py'> 
In [3]: my_package.subpackage1.module_x.main()
spam spam spam

Relative imports are great for creating code that you turn into packages. If you have created a lot of code that is related, then this is probably the way to go. You will find that relative imports are used in many popular packages on the Python Packages Index (PyPI). Also note that if you need to go more than one level, you can just use additional periods. However, according to PEP 328, you really shouldn’t go above two.

Also note that if you were to add an “if __name__ == ‘__main__’” portion to the module_x.py and tried to run it, you would end up with a rather confusing error. Let’s edit the file and give it a try!

from . module_yimport spam as ham
 
def main():
    ham() 
if __name__ == '__main__':
    # This won't work!
    main()

Now navigate into the subpackage1 folder in your terminal and run the following command:


python module_x.py


You should see the following error on your screen for Python 2:

Traceback (most recent call last):
  File "module_x.py", line 1, in<module>from . module_yimport spam as ham
ValueError: Attempted relative importin non-package

And if you tried to run it with Python 3, you’d get this:

Traceback (most recent call last):
  File "module_x.py", line 1, in<module>from . module_yimport spam as ham
SystemError: Parent module ''not loaded, cannot perform relative import

What this means is that module_x.py is a module inside of a package and you’re trying to run it as a script, which is incompatible with relative imports.

If you’d like to use this module in your code, you will have to add it to Python’s import search path. The easiest way to do that is as follows:

importsyssys.path.append('/path/to/folder/containing/my_package')import my_package

Note that you want the path to the folder right above my_package, not my_package itself. The reason is that my_package is THE package, so if you append that, you’ll have issues using the package. Let’s move on to optional imports!

Optional imports

Optional imports are used when you have a preferred module or package that you want to use, but you also want a fallback in case it doesn’t exist. You might use optional imports to support multiple versions of software or for speed ups, for example. Here’s an example from the package github2 that demonstrates how you might use optional imports to support different versions of Python:

try:
    # For Python 3from http.clientimport responses
exceptImportError:  # For Python 2.5-2.7try:
        fromhttplibimport responses  # NOQAexceptImportError:  # For Python 2.4fromBaseHTTPServerimport BaseHTTPRequestHandler as _BHRH
        responses = dict([(k, v[0])for k, v in _BHRH.responses.items()])

The lxml package also makes use of optional imports:

try:
    fromurlparseimport urljoin
    fromurllib2import urlopen
exceptImportError:
    # Python 3fromurllib.parseimport urljoin
    fromurllib.requestimport urlopen

As you can see, it’s used all the time to great effect and is a handy tool to add to your repertoire.

Local imports

A local import is when you import a module into local scope. When you do your imports at the top of your Python script file, that is importing the module into your global scope, which means that any functions or methods that follow will be able to use it. Let’s look at how importing into a local scope works:

importsys# global scope 
def square_root(a):
    # This import is into the square_root functions local scopeimportmathreturnmath.sqrt(a) 
def my_pow(base_num, power):
    returnmath.pow(base_num, power) 
if __name__ == '__main__':
    print(square_root(49))print(my_pow(2, 3))

Here we import the sys module into the global scope, but we don’t actually use it. Then in the square_root function we import Python’s math module into the function’s local scope, which means that the math module can only be used inside of the square_root function. IF we try to use it in the my_pow function, we will receive a NameError. Go ahead and try running the code to see this in action!

One of the benefits of using local scope is that you might be using a module that takes a long time to load. If so, it might make sense to put it into a function that is called rarely rather than your module’s global scope. It really depends on what you want to do. Frankly, I’ve almost never used imports into the local scope, mostly because it can be hard to tell what’s going on if the imports are scattered all over the module. Conventionally, all imports should be at the top of the module after all.

Import Pitfalls

There are some very common import pitfalls that programmers fall into. We’ll go over the two most common here:

• Circular imports
• Shadowed imports

Let’s start by looking at circular imports

Circular imports

Circular imports happen when you create two modules that import each other. Let’s look at an example as that will make it quite clear what I’m referring to. Put the following code into a module called a.py

# a.pyimport b
 
def a_test():
    print("in a_test")
    b.b_test() 
a_test()

Then create another module in the same folder as the one above and name it b.py

import a
 
def b_test():
    print('In test_b"')
    a.a_test() 
b_test()

If you run either of these modules, you should receive an AttributeError. This happens because both modules are attempting to import each other. Basically what’s happening here is that module a is trying to import module b, but it can’t do that because module b is attempting to import module a which is already being executed. I’ve read about some hacky workarounds but in general you should just refactor your code to prevent this kind of thing from happening

Shadowed imports