Introduction

This question usually mixes together two different Python topics: how import module differs from from module import name, and how relative imports use dots such as from . import sibling. The short answer is that import x brings in a module object, from x import y brings a specific name into the current namespace, and import .something is not valid Python syntax at all. Relative imports must use the from form.

import module keeps the namespace explicit

A normal import binds the module object itself.

1import math
2
3print(math.sqrt(9))
4print(math.pi)

This style is explicit because every imported name remains qualified by the module name. It makes it easier to see where sqrt came from and avoids accidental name collisions in the local file.

That is why many style guides prefer plain import module when the module will be used more than once.

from module import name binds a specific name directly

The from ... import ... form pulls selected names into the current namespace.

1from math import sqrt, pi
2
3print(sqrt(9))
4print(pi)

This is shorter to type, but it also means the local namespace now contains sqrt and pi directly. That can be fine for well-known names, yet it can also make source tracking harder in larger files.

So the real tradeoff is:

• shorter call sites
• less namespace clarity

Neither form is universally better. The right choice depends on readability in the surrounding code.

Relative imports use dots, but only with from

Inside a package, dots mean "relative to the current package." The important rule is that relative imports are written with from, not plain import.

Valid examples:

from . import utils
from .helpers import format_name
from ..core import config

Invalid example:

# invalid syntax
# import .utils

That is the key answer if someone is asking about "import .". Python does not support that form.

Why relative imports exist

Relative imports are useful when modules inside the same package need to import one another without hard-coding the full top-level package path. That can make package-internal refactoring easier.

For example, in a package structure like this:

1myapp/
2    __init__.py
3    api/
4        __init__.py
5        views.py
6        utils.py

views.py can import utils.py with:

from . import utils

That says "import the sibling module from the current package."

Absolute imports are often clearer for top-level code

For application entry points and widely shared modules, absolute imports are often easier to understand:

from myapp.api import utils

This makes the origin unambiguous. Relative imports are best when the relationship to the current package is the main point.

One practical warning: relative imports work only when the code is actually executed as part of a package. If you run a module file directly in the wrong way, relative imports often fail because Python does not know the package context.

Common Pitfalls

The most common mistake is assuming import .foo should work because from . import foo works. It does not. Relative imports require the from syntax.

Another issue is overusing from module import *. That pollutes the namespace and makes code harder to reason about.

Developers also confuse package-relative dots with attribute access dots. In imports, the dots are part of module resolution, not object navigation.

Finally, if a relative import raises ModuleNotFoundError or similar package errors, check how the file is being executed. Package imports depend on the module being run in the correct package context.

Summary

• 'import module imports the module object and keeps names qualified.'
• 'from module import name imports specific names directly into the current namespace.'
• Relative imports use dots, but only in the from ... import ... form.
• 'import .something is invalid Python syntax.'
• Use the form that makes namespace ownership and package structure clearest in the surrounding code.