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

Add Eric Araujo's suggestions, plus typo fix.

This commit is contained in:
pje 2011-08-11 14:29:06 -04:00
parent b1b6360f57
commit 3fb53b43da
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
pep-0402.txt Normal file → Executable file
View File

@ -48,7 +48,7 @@ The Problem
When new users come to Python from other languages, they are often
confused by Python's packaging semantics. At Google, for example,
confused by Python's package import semantics. At Google, for example,
Guido received complaints from "a large crowd with pitchforks" [2]_
that the requirement for packages to contain an ``__init__`` module
was a "misfeature", and should be dropped.
@ -434,7 +434,7 @@ is, if ``foo`` and ``foo.bar`` are pure virtual packages, then
``import foo.bar.baz`` must wait until ``foo.bar.baz`` is found before
creating module objects for *both* ``foo`` and ``foo.bar``, and then
create both of them together, properly setting the ``foo`` module's
``.bar`` attrbute to point to the ``foo.bar`` module.
``.bar`` attribute to point to the ``foo.bar`` module.
In this way, pure virtual packages are never directly importable:
an ``import foo`` or ``import foo.bar`` by itself will fail, and the
@ -603,7 +603,7 @@ For users, developers, and distributors of virtual packages:
accidentally work. Is that good or bad?
For those implementing PEP \302 importer objects:
For those implementing PEP 302 importer objects:
* Importers that support the ``iter_modules()`` method (used by
``pkgutil`` to locate importable modules and packages) and want to