iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Put two spaces after the end of sentences, so that emacs does a better job at reflowing text.

This commit is contained in:
Eric V. Smith 2012-04-25 13:33:23 -04:00
parent 32753d298e
commit 481d0d80c3
1 changed files with 45 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
pep-0420.txt
View File

@ -44,8 +44,8 @@ This PEP describes a new type of package, the "namespace package".
Namespace packages today
========================
Python currently provides ``pkgutil.extend_path`` to denote a package as
a namespace package. The recommended way of using it is to put::
Python currently provides ``pkgutil.extend_path`` to denote a package
as a namespace package. The recommended way of using it is to put::
from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)
@ -144,12 +144,12 @@ deferred until a sub-level import occurs.
Impact on Import Finders and Loaders
------------------------------------
PEP 302 defines "finders" that are called to search path
elements. These finders' ``find_module`` methods currently return
either a "loader" object or None. For a finder to contribute to
namespace packages, ``find_module`` will return a third type: a
string. This is the string that will be recorded and later used as a
component of the namespace module's __path__, as described above.
PEP 302 defines "finders" that are called to search path elements.
These finders' ``find_module`` methods currently return either a
"loader" object or None. For a finder to contribute to namespace
packages, ``find_module`` will return a third type: a string. This is
the string that will be recorded and later used as a component of the
namespace module's __path__, as described above.
[Consider Brett's idea to pass NamespaceLoader in to PathFinder]
@ -164,15 +164,15 @@ path. With namespace packages, all entries in the path must be
scanned.
Note that an ImportWarning will no longer be raised for a directory
lacking an ``__init__.py`` file. Such a directory will now be imported
as a namespace package, whereas in prior Python versions an
lacking an ``__init__.py`` file. Such a directory will now be
imported as a namespace package, whereas in prior Python versions an
ImportError would be raised.
At PyCon 2012, we had a discussion about namespace packages at which
PEP 382 and PEP 402 were rejected, to be replaced by this PEP [2]_.
Nick Coglan presented a list of his objections to this proposal
[3]_. They are:
Nick Coglan presented a list of his objections to this proposal [3]_.
They are:
* Implicit package directories go against the Zen of Python
@ -197,18 +197,18 @@ there are two portions which define "foo.bar" and "foo.baz". "foo"
itself is a namespace package.
If these are installed in the same location, a single directory "foo"
would be in a directory that is on ``sys.path``. Inside "foo" would be
two directories, "bar" and "baz". If "foo.bar" is removed (perhaps by
an automatic packager), care must be taken not to remove the "foo/baz"
or "foo" directories. Note that in this case "foo" will be a namespace
package (because it lacks an ``__init__.py``, even though all of its
portions are in the same directory.
would be in a directory that is on ``sys.path``. Inside "foo" would
be two directories, "bar" and "baz". If "foo.bar" is removed (perhaps
by an automatic packager), care must be taken not to remove the
"foo/baz" or "foo" directories. Note that in this case "foo" will be
a namespace package (because it lacks an ``__init__.py``, even though
all of its portions are in the same directory.
If the portions are installed in different locations, two different
"foo" directories would be in directories that are on
``sys.path``. "foo/bar" would be in one of these sys.path entries, and
"foo/baz" would be in the other. Upon removal of "foo.bar", the
"foo/bar" and corresonding "foo" directories can be removed.
"foo" directories would be in directories that are on ``sys.path``.
"foo/bar" would be in one of these sys.path entries, and "foo/baz"
would be in the other. Upon removal of "foo.bar", the "foo/bar" and
corresonding "foo" directories can be removed.
Note that even if they are installed in the same directory, "foo.bar"
and "foo.baz" would not have any files in common.