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?
Understood the valid points people put here. However, I do have one argument that, sometimes, "star import" may not always be a bad practice:
const.py
:
import const
, then for every constant, I have to refer it as const.SOMETHING
, which is probably not the most convenient way.from const import SOMETHING_A, SOMETHING_B ...
, then obviously it's way too verbose and defeats the purpose of the structuring.from const import *
may be a better choice.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.
These are all good answers. I'm going to add that when teaching new people to code in Python, dealing with import *
is very difficult. Even if you or they didn't write the code, it's still a stumbling block.
I teach children (about 8 years old) to program in Python to manipulate Minecraft. I like to give them a helpful coding environment to work with (Atom Editor) and teach REPL-driven development (via bpython). In Atom I find that the hints/completion works just as effectively as bpython. Luckily, unlike some other statistical analysis tools, Atom is not fooled by import *
.
However, lets take this example... In this wrapper they from local_module import *
a bunch modules including this list of blocks. Let's ignore the risk of namespace collisions. By doing from mcpi.block import *
they make this entire list of obscure types of blocks something that you have to go look at to know what is available. If they had instead used from mcpi import block
, then you could type walls = block.
and then an autocomplete list would pop up.
It is OK to do from ... import *
in an interactive session.
As a test, I created a module test.py with 2 functions A and B, which respectively print "A 1" and "B 1". After importing test.py with:
import test
. . . I can run the 2 functions as test.A() and test.B(), and "test" shows up as a module in the namespace, so if I edit test.py I can reload it with:
import importlib
importlib.reload(test)
But if I do the following:
from test import *
there is no reference to "test" in the namespace, so there is no way to reload it after an edit (as far as I can tell), which is a problem in an interactive session. Whereas either of the following:
import test
import test as tt
will add "test" or "tt" (respectively) as module names in the namespace, which will allow re-loading.
If I do:
from test import *
the names "A" and "B" show up in the namespace as functions. If I edit test.py, and repeat the above command, the modified versions of the functions do not get reloaded.
And the following command elicits an error message.
importlib.reload(test) # Error - name 'test' is not defined
If someone knows how to reload a module loaded with "from module import *", please post. Otherwise, this would be another reason to avoid the form:
from module import *
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.