Master Python Imports: Choose import, from, or * and Avoid Common Pitfalls

1) "import X" vs "from X import Y"

We have two files— main.py is the script we run, and helper.py is the module we import from.

There are two main ways to import:

import X

and

from X import Y

Both forms are valid, each with pros and cons:

With from helper import testfunc you can call testfunc() directly, whereas with import helper you must call helper.testfunc() .

In larger, more complex applications, from helper import testfunc is more likely to cause namespace conflicts by unintentionally overwriting same‑named functions or variables.

Conversely, import helper keeps the imported names inside the helper namespace, preventing accidental overwrites.

2) "from X import Y" vs "from X import *"

from helper import testfunc imports only the testfunc function.

from helper import * imports everything defined in helper.py .

Although from helper import * looks convenient, it is considered bad practice because it can unintentionally overwrite existing names with those from the imported module.

Therefore, it is usually better to explicitly list the symbols you need rather than importing everything.

3) Using __import__ for dynamic imports

__import__ allows you to import a module whose name is given as a string, enabling dynamic imports.

4) sys.path and import locations

When Python imports a module, it searches a list of directories stored in sys.path . You can view this list by printing sys.path .

If you try to import pandas , Python first looks in the first directory in sys.path (e.g., /Users/me/Documents/test ). If the module is not found there, Python proceeds to the next directory, and so on, until the list is exhausted, at which point an ImportError is raised.

5) Manually adding entries to sys.path

sys.path is just a plain list of strings; Python searches the directories listed there for modules.

Suppose you need to import a function from /some/weird/path/test.py while your main script resides at /our/main/path/main.py . You can simply append /some/weird/path to sys.path so that Python knows to search that location.

6) PEP8 import order

PEP8 is the style guide for Python code. It recommends ordering imports in three groups, separated by a blank line:

Standard‑library imports (e.g., os, sys, json, re )

Related third‑party imports (e.g., pandas, numpy, fastapi )

Local application/library specific imports (e.g., our_custom_modules )

Note that Python does not enforce this ordering, but many teams (and technical leads) expect it.

7) __all__ and exporting from a module

The special variable __all__ controls what is exported when a module is imported using from module import * .

Assume helper.py defines many functions but sets __all__ = ["hello", "hi"] . Then only hello and hi are exported by from helper import * ; other names such as hola or nihao are not imported.

8) Variables starting with _ are not imported with *

In helper.py we have two regular functions and two functions whose names start with an underscore. When executing from helper import * , the underscore‑prefixed names are omitted from the import.

9) PYTHONPATH environment variable

PYTHONPATH is an optional environment variable. When defined, its value is automatically added to sys.path .

If PYTHONPATH is not set, Python uses only the default search paths. When we set PYTHONPATH to /some/funny/path , that directory is appended to sys.path , and Python will search it during imports.

10) Using __name__ during import

__name__ is a special variable that equals "__main__" when a file is executed directly, and equals the module's filename when the file is imported.

This is why the idiom if __name__ == "__main__": is used to ensure that a block of code runs only when the script is run as the entry point, not when it is imported as a module.