In python, why is "import *" bad?

Question

It is recommended to not to use import * in python. Can anyone please share the reason for that, so that I can avoid it doing next time.

Thanks and Regards

Answer 1

• Because it puts a lot of stuff into your namespace (might shadow some other object from previous import and you won't know about it).

• Because you don't know exactly what is imported and can't find place from what module certain thing was imported easily (readability).

• Because you can't use cool tools like pyflakes to detect statically errors in your code.

Answer 2

http://docs.python.org/tutorial/modules.html

Note that in general the practice of importing * from a module or package is frowned upon, since it often causes poorly readable code.

Answer 3

That is because you are polluting the namespace. You will import all the funtions and classes in your own namespace, which may clash with the functions you define yourself.

Furthermore, I think using a qualified name is more clear for the maintenance task; you see on the code line itself where a function comes from, so you can check out the docs much more easily.

In module foo:

def myFunc():
    print 1

In your code:

from foo import *

def doThis():
    myFunc() # Which myFunc is called?

def myFunc():
    print 2

Answer 4

It is OK to do from ... import * in an interactive session.

Answer 5

According to the Python Zen:

Explicit is better than implicit.

... can't argue with that, surely?

Answer 6

say you have the following code in a module called foo:

import ElementTree as etree

and then in your own module you have:

from lxml import etree
from foo import *

You now have a difficult-to-debug module that looks like it has lxml's etree in it, but really has ElementTree instead.

Answer 7

You don't pass **locals() to functions, do you?

Since Python lacks an "include" statement, and the self parameter is explicit, and scoping rules are quite simple, it's usually very easy to point a finger at a variable and tell where that object comes from -- without reading other modules and without any kind of IDE (which are limited in the way of introspection anyway, by the fact the language is very dynamic).

The import * breaks all that.

Also, it has a concrete possibility of hiding bugs.

import os, sys, foo, sqlalchemy, mystuff
from bar import *

Now, if the bar module has any of the "os", "mystuff", etc... attributes, they will override the explicitly imported ones, and possibly point to very different things. Defining __all__ in bar is often wise -- this states what will implicitly be imported - but still it's hard to trace where objects come from, without reading and parsing the bar module and following its imports. A network of import * is the first thing I fix when I take ownership of a project.

Don't misunderstand me: if the import * were missing, I would cry to have it. But it has to be used carefully. A good use case is to provide a facade interface over another module. Likewise, the use of conditional import statements, or imports inside function/class namespaces, requires a bit of discipline.

I think in medium-to-big projects, or small ones with several contributors, a minimum of hygiene is needed in terms of statical analysis -- running at least pyflakes or even better a properly configured pylint -- to catch several kind of bugs before they happen.

Of course since this is python -- feel free to break rules, and to explore -- but be wary of projects that could grow tenfold, if the source code is missing discipline it will be a problem.

Answer 8

Pleeese, can anybody give a reasonable answer here?!

Stuff like "It doesn't matter why. Just avoid bad things" just repeats garbage from many books, which also say "bad" and "avoid" but don't give an honest _two_sided_ comparison between alternatives. If it was all one sided, then why mess up the language with alternatives...

OK, so polluting the namespace is true and trivially obvious. Mentioned in every writeup. This problem can be avoided if the included module is carefully designed to use a single and unique enough prefix for all variables, objects, etc...

-1-
Is there any speed advantage for include *. For example, is addressing in large loops included items from say module AG, like AG.AG_itemBlah versus if included * and addressing them as AG_itemBlah.

Most books warn that there is a speed penalty for every dot in variable. Apparently Python's design makes it impossible for the interpreter to optimize those dots out before the loops. Programmers can often do it creating temporary variables, but it's UGLY and messy.

So if include * saves speed, there would be a good reason to design config modules for example with this in mind!

-2- Argument about pyflakes debugger choking on these includes is a good argument. But it seems there is no pyflakes for Python 3.x anyway? Are there any other Python debuggers which can deal intelligently with include *

Thanks

ps. And please, no boring pseudo arguments that when using Python speed doesn't matter.