Importing modules in Python – best practice

by

Disadvantage of each form

When reading other people’s code (and those people use very
different importing styles), I noticed the following problems with
each of the styles:

import modulewithaverylongname will clutter the code further down
with the long module name (e.g. concurrent.futures or django.contrib.auth.backends) and decrease readability in those places.

from module import * gives me no chance to see syntactically that,
for instance, classA and classB come from the same module and
have a lot to do with each other.
It makes reading the code hard.
(That names from such an import
may shadow names from an earlier import is the least part of that problem.)

from module import classA, classB, functionC, constantD, functionE
overloads my short-term memory with too many names
that I mentally need to assign to module in order to
coherently understand the code.

import modulewithaverylongname as mwvln is sometimes insufficiently
mnemonic to me.

A suitable compromise

Based on the above observations, I have developed the following
style in my own code:

import module is the preferred style if the module name is short
as for example most of the packages in the standard library.
It is also the preferred style if I need to use names from the module in
only two or three places in my own module;
clarity trumps brevity then (“Readability counts”).

import longername as ln is the preferred style in almost every
other case.
For instance, I might import django.contrib.auth.backends as djcab.
By definition of criterion 1 above, the abbreviation will be used
frequently and is therefore sufficiently easy to memorize.

Only these two styles are fully pythonic as per the
“Explicit is better than implicit.” rule.

from module import xx still occurs sometimes in my code.
I use it in cases where even the as format appears exaggerated,
the most famous example being from datetime import datetime
(but if I need more elements, I will import datetime as dt).

More Related Contents:

  1. Should I use `import os.path` or `import os`?
  2. Best way to return multiple values from a function? [closed]
  3. How to fix “Attempted relative import in non-package” even with __init__.py
  4. ImportError: Cannot import name X
  5. Import a file from a subdirectory?
  6. Reading file using relative path in python project
  7. Relative imports in Python 3
  8. Relative imports – ModuleNotFoundError: No module named x
  9. Importing an ipynb file from another ipynb file?
  10. Does python optimize modules when they are imported multiple times?
  11. How to import a Python class that is in a directory above?
  12. PYTHONPATH vs. sys.path
  13. How to dynamically load a Python class
  14. Imports in __init__.py and ‘import as’ statement
  15. Python exception chaining [duplicate]
  16. Importing packages in Python
  17. Absolute imports in python not working, relative imports work
  18. Local import statements in Python
  19. How does one do the equivalent of “import * from module” with Python’s __import__ function?
  20. Is nested function a good approach when required by only one function? [closed]
  21. How to solve import error for pandas?
  22. Python: is the current directory automatically included in path?
  23. identity versus equality for None in Python
  24. Airflow “This DAG isnt available in the webserver DagBag object “
  25. Importing a library from (or near) a script with the same name raises “AttributeError: module has no attribute” or an ImportError or NameError
  26. How can I do relative imports in Python?
  27. How can we force naming of parameters when calling a function?
  28. bash: Python import – Command not found for pandas
  29. Length of longest word in a list
  30. Import statement works on PyCharm but not from terminal

Leave a Comment