104
104
This imports all names except those beginning with an underscore (``_``).
106
Note that in general the practice of importing ``*`` from a module or package is
107
frowned upon, since it often causes poorly readable code. However, it is okay to
108
use it to save typing in interactive sessions.
108
112
For efficiency reasons, each module is only imported once per interpreter
444
448
Now what happens when the user writes ``from sound.effects import *``? Ideally,
445
449
one would hope that this somehow goes out to the filesystem, finds which
446
submodules are present in the package, and imports them all. Unfortunately,
447
this operation does not work very well on Windows platforms, where the
448
filesystem does not always have accurate information about the case of a
449
filename! On these platforms, there is no guaranteed way to know whether a file
450
:file:`ECHO.PY` should be imported as a module :mod:`echo`, :mod:`Echo` or
451
:mod:`ECHO`. (For example, Windows 95 has the annoying practice of showing all
452
file names with a capitalized first letter.) The DOS 8+3 filename restriction
453
adds another interesting problem for long module names.
450
submodules are present in the package, and imports them all. This could take a
451
long time and importing sub-modules might have unwanted side-effects that should
452
only happen when the sub-module is explicitly imported.
455
454
The only solution is for the package author to provide an explicit index of the
456
package. The import statement uses the following convention: if a package's
455
package. The :keyword:`import` statement uses the following convention: if a package's
457
456
:file:`__init__.py` code defines a list named ``__all__``, it is taken to be the
458
457
list of module names that should be imported when ``from package import *`` is
459
458
encountered. It is up to the package author to keep this list up-to-date when a
474
473
and then imports whatever names are defined in the package. This includes any
475
474
names defined (and submodules explicitly loaded) by :file:`__init__.py`. It
476
475
also includes any submodules of the package that were explicitly loaded by
477
previous import statements. Consider this code::
476
previous :keyword:`import` statements. Consider this code::
479
478
import sound.effects.echo
480
479
import sound.effects.surround
481
480
from sound.effects import *
483
In this example, the echo and surround modules are imported in the current
484
namespace because they are defined in the :mod:`sound.effects` package when the
485
``from...import`` statement is executed. (This also works when ``__all__`` is
482
In this example, the :mod:`echo` and :mod:`surround` modules are imported in the
483
current namespace because they are defined in the :mod:`sound.effects` package
484
when the ``from...import`` statement is executed. (This also works when
485
``__all__`` is defined.)
488
Note that in general the practice of importing ``*`` from a module or package is
489
frowned upon, since it often causes poorly readable code. However, it is okay to
490
use it to save typing in interactive sessions, and certain modules are designed
491
to export only names that follow certain patterns.
487
Although certain modules are designed to export only names that follow certain
488
patterns when you use ``import *``, it is still considered bad practise in
493
491
Remember, there is nothing wrong with using ``from Package import
494
492
specific_submodule``! In fact, this is the recommended notation unless the
added
removed
Doc/tutorial/modules.rst
