Python: Why should 'from <module> import *' be prohibited?

Question

If you happen to have

from <module> import *

in the middle of your program (or module), you would get the warning:

/tmp/foo:100: SyntaxWarning: import * only allowed at module level

I understand why import * is discouraged in general (namespace invisibility), but there are many situations where it would prove convenient, especially where code is not shared with anyone.

So, can anyone explain precisely in detail why from <module> import * should be prohibited in all possible cases?

Answer 1

I believe by "in the middle of your program" you are talking about this kind of thing:

def f():
    from module import *    # not allowed

This is because it would make optimizing the body of the function much too hard. The Python implementation wants to know all of the names of function-local variables when it byte-compiles a function, so that it can optimize variable references into operations on the (CPython) virtual machine's operand stack, or at least to local variable-slot operations rather than lookups in outer namespaces. If you could dump the entire contents of a module into a function's local namespace, then the compiler would have to assume that any name in the function might possibly refer to a module global, because the list of names brought in by from module import * is only known at runtime.

I don't have a Python interpreter on this computer so I can't check, but if I remember correctly, this is valid, albeit poor style:

def f():
    ...

from module import *

def g():
    ...

Also note that there are some weasel words in http://docs.python.org/reference/simple_stmts.html#the-import-statement :

The from form with * may only occur in a module scope. If the wild card form of import — import * — is used in a function and the function contains or is a nested block with free variables, the compiler will raise a SyntaxError.

Emphasis mine. I don't know exactly what that means, but it sounds like you may be able to get away with function-scope from module import * in some circumstances (but note further that those weasel words are gone in the v3.2 edition of that document).

Answer 2

The release notes for Python 2.1 seem to explain why this limitation exists:

One side effect of the change is that the from module import * and exec statements have been made illegal inside a function scope under certain conditions. The Python reference manual has said all along that from module import * is only legal at the top level of a module, but the CPython interpreter has never enforced this before. As part of the implementation of nested scopes, the compiler which turns Python source into bytecodes has to generate different code to access variables in a containing scope. from module import * and exec make it impossible for the compiler to figure this out, because they add names to the local namespace that are unknowable at compile time. Therefore, if a function contains function definitions or lambda expressions with free variables, the compiler will flag this by raising a SyntaxError exception.

Answer 3

It's not prohibited at all. It works fine, but you get a warning because it's generally a bad idea (for reasons others have gone into). You can, if you like, suppress the warning; the warnings module is what you want for that.

Answer 4

At any lexical level, from amodule import * is a "seemed a good idea at the time" design decision that has proven a real disaster in real life, with the possible exception of handy exploration at the interactive interpreter prompt (even then, I'm not too hot on it -- import module as m forces only two extra characters to use qualified names instead [[just an m. prefix]], and qualified names are always sharper and more flexible than barenames, not to mention the great usefulness in exploratory interactive situations of having m available for help(m), reload(m), and the like!).

This bedraggled construct makes it very hard, for the poor person reading the code (often in a doomed attempt to help debug it) to understand where mysteriously-appearing names are coming from -- impossible, if the construct is used more than once on a lexical level; but even when used just once, it forces laborious re-reading of the whole module every time before one can convince oneself that, yep, that bedraggled barename must come from the module.

Plus, module authors usually don't go to the extreme trouble needed to "support" the horrid construct in question. If somewhere in your code you have, say, a use of sys.argv (and an import sys at the very top of your module, of course), how do you know that sys is the module it should be... or some completely different one (or a non-module) coming from the ... import *?! Multiply that by all the qualified names you're using, and misery is the only end result -- that, and mysterious bugs requiring long, laborious debugging (usually with the reluctant help of somebody who does "get" Python...!-).

Within a function, a way to add and override arbitrary local names would be even worse. As an elementary but crucial optimization, the Python compiler looks around the function's body for any assignment or other binding statements on each barename, and deems "local" those names it sees thus assigned (the others must be globals or built-ins). With an import * (just like with an exec somestring without explicit dicts to use as namespaces), suddenly it becomes a total mystery which names are local, which names are global -- so the poor compiler would have to resort to the slowest possible strategy for each name lookup, using a dict for local variables (instead of the compact "vector" it normally uses) and performing up to three dict look-ups for each barename referenced, over and over.

Go to any Python interactive prompt. Type import this. What do you see? The Zen of Python. What's the last and probably greatest bit of wisdom in that text...?

Namespaces are one honking great idea -- let's do more of those!

By forcing the use of barenames where qualified names are so vastly preferable, you're essentially doing the very opposite of this wise recommendation: instead of admiring the greatness and honkingtude of namespaces, and doing more of those, you're breaking down two perfectly good and ready-to-use namespaces (that of the module you're importing, and that of the lexical scope you're importing it in) to make a single, unholy, buggy, slow, rigid, unusable mess.

If I could go back and change one early design decision in Python (it's a hard choice, because the use of def and especially lambda for what Javascript so much more readably calls function is a close second;-), I would retroactively wipe out the import * idea from Guido's mind. No amount of alleged convenience for exploration at the interactive prompt can balance the amount of evil it's wrought...!-)

Answer 5

others have given in-depth answers, I'll give a short overview answer of my understanding.. when using from you are making it so you can directly call any function in that module you imported without doing modulename.functioname (you can just call "functionname") this creates problems if you have 2 functions of the same name in different modules and also can create confusion when dealing with a lot of functions as you don't know what object/module it belongs to (from point of view of someone looking over already written code that isn't familiar with it)

Answer 6

It's not prohibited, because...

... it's handy for quick scripts and shell exploring.

...but you should not keep it in any serious code

1. it can lead in importing names you don't know about and erase local names
2. you can't know what's in use in your code, it's hard to know a script dependencies
3. code completions won't work correctly anymore
4. IDE convenient checks like "this var has not been declared" can't work anymore
5. it make easier to create circular imports