The "advantage" of from xyz import *
as opposed to other forms of import is that it imports everything (well, almost... [see (a) below] everything) from the designated module under the current module. This allows using the various objects (variables, classes, methods...) from the imported module without prefixing them with the module's name. For example
>>> from math import *
>>>pi
3.141592653589793
>>>sin(pi/2)
>>>1.0
This practice (of importing * into the current namespace) is however discouraged because it
- provides the opportunity for namespace collisions (say if you had a variable name pi prior to the import)
- may be inefficient, if the number of objects imported is big
- doesn't explicitly document the origin of the variable/method/class (it is nice to have this "self documentation" of the program for future visit into the code)
Typically we therefore limit this import * practice to ad-hoc tests and the like. As pointed out by @Denilson-Sá-Maia, some libraries such as (e.g. pygame) have a sub-module where all the most commonly used constants and functions are defined and such sub-modules are effectively designed to be imported with import *
. Other than with these special sub-modules, it is otherwise preferable to ...:
explicitly import a few objects only
>>>from math import pi
>>>pi
>>>3.141592653589793
>>> sin(pi/2)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'sin' is not defined
or import the module under its own namespace (or an alias thereof, in particular if this is a long name, and the program references its objects many times)
>>>import math
>>>math.pi
>>>3.141592653589793
etc..
>>>import math as m #bad example math being so short and standard...
>>>m.pi
>>>3.141592653589793
etc..
See the Python documentation on this topic
(a) Specifically, what gets imported with from xyz import *
?
if xyz module defines an __all__
variable, it will import all the names defined in this sequence, otherwise it will import all names, except these which start with an underscore.
Note Many libraries have sub-modules. For example the standard library urllib
includes sub-modules like urllib.request
, urllib.errors
, urllib.response
etc. A common point of confusion is that
from urllib import *
would import all these sub-modules. That is NOT the case: one needs to explicitly imports these separately with, say, from urllib.request import *
etc. This incidentally is not specific to import *
, plain import
will not import sub-modules either (but of course, the *
which is often a shorthand for "everything" may mislead people in thinking that all sub-modules and everything else would be imported).
First statement imports the specified module into the current namespace.
Second statement imports everything from the specified module into the current namespace.
So 1) means you still need to explicitly reference any classes/functions etc through the module namespace
2) Means you don't
Here's a compare and contrast that shows the difference
1)
import math
d = math.sqrt(10)
2)
from math import *
d = sqrt(10)
Note that you can choose to import a specific symbol from a module if you want i.e.
from math import sqrt
d = sqrt(10)
Best Answer
Yes, your observations are correct. This is a consequence of the way that binding works in Python.
When one does
then
foo
becomes a global name that references the modulefoo
. When one doesThen the reference is followed and the object
foo
is loaded. Then7
is stored in thebar
attribute.When another module imports
foo
, it just pulls the object out ofsys.modules['foo']
and gets the modified value.When one does
globals()['bar']
is set to referencefoo.bar
. When one later doesglobals()['bar']
no longer referencesfoo.bar
but references a copy of7
. That is, the original binding in the global scope of the importing module is simply replaced.In the fist example, one is modifying attributes of an object that is stored in
sys.modules
and will be common to all modules that have imported it. In the second example, one is modifying the global scope of the importing module.If one was to do something along the lines of
Then that change would be propagated to other importing modules because one is not overwriting the global reference but following it to modify an attribute of the object that it points to. So essentially, you should be able to modify mutable objects so long as you don't overwrite the global binding.
I think that something like this is the closest that you are going to be able to cleanly get to a true global in python. As a language, it greatly values namespaces.