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).
__future__
features are self-documenting. Try this:
>>> from __future__ import with_statement
>>> with_statement.getOptionalRelease()
(2, 5, 0, 'alpha', 1)
>>> with_statement.getMandatoryRelease()
(2, 6, 0, 'alpha', 0)
These respectively indicate the first release supporting from __future__ import with_statement
and the first release to support it without using from __future__
.
Also, read this:
>>> import __future__
>>> help(__future__)
Best Answer
from __future__ import print_function
tells the parser to not treatprint
as a keyword (leaving it as a name instead). That way the compiler treats it as the function and not a statement.To track this, the
compiler
struct has ac_future
field that holds aPyFutureFeatures
object that tracks which future directives have been enabled. Various parts of the parser and compiler check the flags and alter behaviour.This is mostly handled in the
future.c
source file, which has afuture_parse()
function that checks forimport from
AST objects with the module parameter set to__future__
, and sets flags based on what is found.For example, for the
barry_as_FLUFL
'feature', the parser refuses!=
as syntax but accepts<>
instead:You can find the other examples by grepping for the
FUTURE_*
flags listed incompile.h
.Note that there is a
__future__
Python module, but it is not directly involved in the parsing and compilation of code; it is merely there to give Python code easy access to metadata about directives (including bitfield values to pass to theflags
argument of thecompile()
function), nothing more.