Python Import Statement

In the last lesson you learned about Python Modules. A module is just a file full of code you can reuse. Now the question is simple. How do you actually pull that code into your own file? That is the job of the import statement. There is more than one way to import. Picking the right one keeps your code clean and easy to read.

🤔 Why Different Import Styles Exist

Say you want to use a ready-made tool. The math module that comes with Python is a good example. Here is the pain. If you type the wrong kind of import, your names can clash. They can get too long to type. Or you lose track of where they came from.

So Python gives you a few import styles. Each one fits a slightly different situation. Once you know what each one does, you just reach for the right one and keep going.

Here are the styles we will look at:

• import module — bring in the whole module
• import module as alias — bring it in under a shorter name
• from module import name — bring in just one thing
• from module import * — bring in everything (the risky one)

📦 import module

This is the plain, everyday import. You bring in the whole module. Then you reach into it with a dot whenever you need something.

Here we import the math module and use its sqrt function to get a square root.

import math

result = math.sqrt(16)
print(result)

4.0

Look at how we call it. We write math.sqrt. We say the module name first, then a dot, then the thing we want. That dot is doing real work. It tells anyone reading the code that sqrt comes from math, and not from somewhere else.

This style is the safest default. The module name stays in front of everything. So there is never any confusion about where a name came from.

🏷️ import module as alias

Sometimes the real module name is long. Or the community has agreed on a short name for it. So you give it a nickname when you import it. That nickname is called an alias.

Here we import math but call it m for short.

import math as m

print(m.pi)
print(m.sqrt(81))

3.141592653589793
9.0

After import math as m, the name math is gone in this file. You now use m everywhere instead. Same module, shorter name.

You will see this a lot with data libraries. People write import numpy as np and import pandas as pd so often that np and pd are basically standard. When you read someone else’s data code, np.array(...) instantly tells you it is NumPy.

🎯 from module import name

What if you only need one function from a big module? And you do not want to type the module name every single time? Then you pull that one name straight in.

Here we grab just sqrt from math, so we can call it on its own.

from math import sqrt

print(sqrt(49))

7.0

Notice there is no math. in front now. We imported sqrt directly. So we call it as plain sqrt. You can pull in more than one thing too. Just separate them with commas.

This example brings in both pi and sqrt in one line.

from math import pi, sqrt

print(pi)
print(sqrt(100))

3.141592653589793
10.0

This style reads nicely when you use the same one or two functions over and over. The trade-off is that the module name is no longer in front. So a reader has to look back at the import line to remember where sqrt came from.

⚠️ from module import * (the risky one)

This last style says one thing. Bring in everything from the module, with no module name in front of any of it.

Here we import everything from math and use a few names directly.

from math import *

print(pi)
print(sqrt(64))
print(floor(3.9))

3.141592653589793
8.0
3

It looks convenient, right? No dots. No typing the module name. But this is the one style most teams tell you to avoid. Here is the problem with wildcard imports:

• You cannot tell where any name came from. Reading sqrt(64) later, you have no clue it is from math.
• It can quietly overwrite your own names. If you have a variable called pi and then run from math import *, your pi is gone.
• Two wildcard imports can clash. If two modules both have a load function, the second import silently wins and you may not notice.

This example shows the silent clash problem in action.

gamma = "my own value"

from math import *

# ❌ Avoid: the import quietly replaced your variable
print(gamma)

<built-in function gamma>

See what happened? You set gamma to your own text. But math also has a gamma function. And from math import * quietly took over the name. Your text is gone. Printing gamma now shows a math function instead of your value. And you got no warning at all. That is exactly why this style is risky.

🧭 When to Use Which

Here is a quick guide to pick the right style without overthinking it.

⚠️ Common Mistakes

A few things trip people up when they start importing. Watch for these.

• Forgetting the dot after a plain import. With import math, you must write math.sqrt, not just sqrt.

import math

# ❌ Avoid: sqrt does not exist on its own here
# print(sqrt(16))   # NameError

# ✅ Good: reach into the module with a dot
print(math.sqrt(16))

• Reaching for the full name after an alias. Once you write import math as m, the name math no longer works in that file.

import math as m

# ❌ Avoid: you renamed it, so math is gone
# print(math.pi)    # NameError

# ✅ Good: use the alias you chose
print(m.pi)

• Using from module import * to save typing. It saves a few keystrokes now and costs you hours of confusion later when a name clashes.

✅ Best Practices

Keep these habits and your imports stay clean and clear.

• Reach for plain import module first. It is the clearest and almost never wrong.
• Use an alias only when it is a recognized one, like np or pd.
• With from module import name, import just the few names you actually use, not a long list.
• Put all your import lines at the top of the file, so anyone can see your dependencies at a glance.
• Never use from module import * in code you plan to keep.

🧩 What You’ve Learned

A quick recap of the import styles and when each one fits.

• ✅ import module brings in the whole module, and you use it with a dot like math.sqrt.
• ✅ import module as alias gives the module a shorter name, like import numpy as np.
• ✅ from module import name pulls one thing in directly, so you call it without the module name in front.
• ✅ from module import * brings in everything and is risky, because it hides where names came from and can overwrite your own names.
• ✅ Plain import module is the safe default, and wildcard imports should be avoided in real code.

🚀 What’s Next?

Now you know how to bring other people’s code into your file. Next you will flip it around and build your own modules so other files can import from you.

Creating Modules