Learning Python - Mark Lutz [331]
I mentioned this earlier but saved the details for here. Because you don’t list the variables you want when using the from module import * statement form, it can accidentally overwrite names you’re already using in your scope. Worse, it can make it difficult to determine where a variable comes from. This is especially true if the from * form is used on more than one imported file.
For example, if you use from * on three modules, you’ll have no way of knowing what a raw function call really means, short of searching all three external module files (all of which may be in other directories):
>>> from module1 import * # Bad: may overwrite my names silently
>>> from module2 import * # Worse: no way to tell what we get!
>>> from module3 import *
>>> . . .
>>> func() # Huh???
The solution again is not to do this: try to explicitly list the attributes you want in your from statements, and restrict the from * form to at most one imported module per file. That way, any undefined names must by deduction be in the module named in the single from *. You can avoid the issue altogether if you always use import instead of from, but that advice is too harsh; like much else in programming, from is a convenient tool if used wisely. Even this example isn’t an absolute evil—it’s OK for a program to use this technique to collect names in a single space for convenience, as long as it’s well known.
reload May Not Impact from Imports
Here’s another from-related gotcha: as discussed previously, because from copies (assigns) names when run, there’s no link back to the modules where the names came from. Names imported with from simply become references to objects, which happen to have been referenced by the same names in the importee when the from ran.
Because of this behavior, reloading the importee has no effect on clients that import its names using from. That is, the client’s names will still reference the original objects fetched with from, even if the names in the original module are later reset:
from module import X # X may not reflect any module reloads!
. . .
from imp import reload
reload(module) # Changes module, but not my names
X # Still references old object
To make reloads more effective, use import and name qualification instead of from. Because qualifications always go back to the module, they will find the new bindings of module names after reloading:
import module # Get module, not names
. . .
from imp import reload
reload(module) # Changes module in-place
module.X # Get current X: reflects module reloads
reload, from, and Interactive Testing
In fact, the prior gotcha is even more subtle than it appears. Chapter 3 warned that it’s usually better not to launch programs with imports and reloads because of the complexities involved. Things get even worse when from is brought into the mix. Python beginners often stumble onto its issues in scenarios like the one outlined next. Say that after opening a module file in a text edit window, you launch an interactive session to load and test your module with from:
from module import function
function(1, 2, 3)
Finding a bug, you jump back to the edit window, make a change, and try to reload the module this way:
from imp import reload
reload(module)
This doesn’t work, because the from statement assigned the name function, not module. To refer to the module in a reload, you have to first load it with an import statement at least once:
from imp import reload
import module
reload(module)
function(1, 2, 3)
However, this doesn’t quite work either—reload updates the module object, but as discussed in the preceding section, names like function that were copied out of the module in the past still refer to the old objects (in this instance, the original version of the function). To really get the new function, you must refer to it as module.function after the reload, or rerun the from:
from imp import reload
import module
reload(module)
from module import function # Or give up and use module.function()
function(1, 2, 3)
Now, the