| I l@ve RuBoard | |
As we've seen, qualification is needed only when you use import to fetch a module as a whole. When you use the from statement, you copy names from the module to the importer, so the imported names are used without qualifying. Here are a few more details on the import process.
One of the most common questions beginners seem to ask when using modules is: why won't my imports keep working? The first import works fine, but later imports during an interactive session (or in a program) seem to have no effect. They're not supposed to, and here's why:
Modules are loaded and run on the first import or from.
Running a module's code creates its top-level names.
Later import and from operations fetch an already loaded module.
Python loads, compiles, and runs code in a module file only on the first import, on purpose; since this is an expensive operation, Python does it just once per process by default. Moreover, since code in a module is usually executed once, you can use it to initialize variables. For example:
% cat simple.py print 'hello' spam = 1 # initialize variable % python >>> import simple # first import: loads and runs file's code hello >>> simple.spam # assignment makes an attribute 1 >>> simple.spam = 2 # change attribute in module >>> >>> import simple # just fetches already-loaded module >>> simple.spam # code wasn't rerun: attribute unchanged 2
In this example, the print and = statements run only the first time the module is imported. The second import doesn't rerun the module's code, but just fetches the already created module object in Python's internal modules table. Of course, sometimes you really want a module's code to be rerun; we'll see how to do it with reload in a moment.
Just like def, import and from are executable statements, not compile-time declarations. They can be nested in if tests, appear in function defs, and so on. Imported modules and names aren't available until importing statements run. Moreover, import and from are also implicit assignments, just like the def:
import assigns an entire module object to a name.
from assigns one or more names to objects of the same name in another module.
All the things we've already said about assignment apply to module access too. For instance, names copied with a from become references to possibly shared objects; like function arguments, reassigning a fetched name has no effect on the module it was copied from, but changing a fetched mutable object can change it in the module it was imported from:[3]
[3] In fact, for a graphical picture of what from does, flip back to Figure 4.2 (function argument passing). Just replace caller and function with imported and importer, to see what from assignments do with references; it's the exact same effect, except that here we're dealing with names in modules, not functions.
% cat small.py x = 1 y = [1, 2] % python >>> from small import x, y # copy two names out >>> x = 42 # changes local x only >>> y[0] = 42 # changes shared mutable in-place >>> >>> import small # get module name (from doesn't) >>> small.x # small's x is not my x 1 >>> small.y # but we share a changed mutable [42, 2]
Here, we change a shared mutable object we got with the from assignment: name y in the importer and importee reference the same list object, so changing it from one place changes it in the other. Incidentally, notice that we have to execute an import statement after the from , in order to gain access to the module name to qualify it; from copies names only in the module and doesn't assign the module name itself. At least symbolically, from is equivalent to this sequence:
import module # fetch the module object name1 = module.name1 # copy names out by assignment name2 = module.name2 ... del module # get rid of the module name
| I l@ve RuBoard | |