Kaydet (Commit) ee2df030 authored tarafından Michael Foord's avatar Michael Foord

Tutorial tweaks. Issue 6849.

üst 668be589
...@@ -103,6 +103,10 @@ There is even a variant to import all names that a module defines:: ...@@ -103,6 +103,10 @@ There is even a variant to import all names that a module defines::
This imports all names except those beginning with an underscore (``_``). This imports all names except those beginning with an underscore (``_``).
Note that in general the practice of importing ``*`` from a module or package is
frowned upon, since it often causes poorly readable code. However, it is okay to
use it to save typing in interactive sessions.
.. note:: .. note::
For efficiency reasons, each module is only imported once per interpreter For efficiency reasons, each module is only imported once per interpreter
...@@ -443,14 +447,9 @@ Importing \* From a Package ...@@ -443,14 +447,9 @@ Importing \* From a Package
Now what happens when the user writes ``from sound.effects import *``? Ideally, Now what happens when the user writes ``from sound.effects import *``? Ideally,
one would hope that this somehow goes out to the filesystem, finds which one would hope that this somehow goes out to the filesystem, finds which
submodules are present in the package, and imports them all. Unfortunately, submodules are present in the package, and imports them all. This could take a
this operation does not work very well on Windows platforms, where the long time and importing sub-modules might have unwanted side-effects that should
filesystem does not always have accurate information about the case of a only happen when the sub-module is explicitly imported.
filename. On these platforms, there is no guaranteed way to know whether a file
:file:`ECHO.PY` should be imported as a module :mod:`echo`, :mod:`Echo` or
:mod:`ECHO`. (For example, Windows 95 has the annoying practice of showing all
file names with a capitalized first letter.) The DOS 8+3 filename restriction
adds another interesting problem for long module names.
The only solution is for the package author to provide an explicit index of the The only solution is for the package author to provide an explicit index of the
package. The :keyword:`import` statement uses the following convention: if a package's package. The :keyword:`import` statement uses the following convention: if a package's
...@@ -485,10 +484,9 @@ current namespace because they are defined in the :mod:`sound.effects` package ...@@ -485,10 +484,9 @@ current namespace because they are defined in the :mod:`sound.effects` package
when the ``from...import`` statement is executed. (This also works when when the ``from...import`` statement is executed. (This also works when
``__all__`` is defined.) ``__all__`` is defined.)
Note that in general the practice of importing ``*`` from a module or package is Although certain modules are designed to export only names that follow certain
frowned upon, since it often causes poorly readable code. However, it is okay to patterns when you use ``import *``, it is still considered bad practise in
use it to save typing in interactive sessions, and certain modules are designed production code.
to export only names that follow certain patterns.
Remember, there is nothing wrong with using ``from Package import Remember, there is nothing wrong with using ``from Package import
specific_submodule``! In fact, this is the recommended notation unless the specific_submodule``! In fact, this is the recommended notation unless the
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment