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

Issue #26914: Fix formatting of lists in PEP 420 

Patch by Ned Batchelder.
This commit is contained in:
Berker Peksag 2016-05-03 10:36:46 +03:00
parent 30ad98f0b1
commit 936292e0c4
1 changed files with 78 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
pep-0420.txt
View File

@ -30,16 +30,21 @@ Within this PEP:
* "package" refers to Python packages as defined by Python's import * "package" refers to Python packages as defined by Python's import
statement. statement.
* "distribution" refers to separately installable sets of Python * "distribution" refers to separately installable sets of Python
modules as stored in the Python package index, and installed by modules as stored in the Python package index, and installed by
distutils or setuptools. distutils or setuptools.
* "vendor package" refers to groups of files installed by an * "vendor package" refers to groups of files installed by an
operating system's packaging mechanism (e.g. Debian or Redhat operating system's packaging mechanism (e.g. Debian or Redhat
packages install on Linux systems). packages install on Linux systems).
* "regular package" refers to packages as they are implemented in * "regular package" refers to packages as they are implemented in
Python 3.2 and earlier. Python 3.2 and earlier.
* "portion" refers to a set of files in a single directory (possibly * "portion" refers to a set of files in a single directory (possibly
stored in a zip file) that contribute to a namespace package. stored in a zip file) that contribute to a namespace package.
* "legacy portion" refers to a portion that uses ``__path__`` * "legacy portion" refers to a portion that uses ``__path__``
manipulation in order to implement namespace packages. manipulation in order to implement namespace packages.
@ -550,13 +555,17 @@ module. The rules for producing a module repr are now standardized as:
* If the module has an ``__loader__`` and that loader has a ``module_repr()`` * If the module has an ``__loader__`` and that loader has a ``module_repr()``
method, call it with a single argument, which is the module object. The method, call it with a single argument, which is the module object. The
value returned is used as the module's repr. value returned is used as the module's repr.
* If an exception occurs in ``module_repr()``, the exception is * If an exception occurs in ``module_repr()``, the exception is
caught and discarded, and the calculation of the module's repr caught and discarded, and the calculation of the module's repr
continues as if ``module_repr()`` did not exist. continues as if ``module_repr()`` did not exist.
* If the module has an ``__file__`` attribute, this is used as part of the * If the module has an ``__file__`` attribute, this is used as part of the
module's repr. module's repr.
* If the module has no ``__file__`` but does have an ``__loader__``, then the * If the module has no ``__file__`` but does have an ``__loader__``, then the
loader's repr is used as part of the module's repr. loader's repr is used as part of the module's repr.
* Otherwise, just use the module's ``__name__`` in the repr. * Otherwise, just use the module's ``__name__`` in the repr.
Here is a snippet showing how namespace module reprs are calculated Here is a snippet showing how namespace module reprs are calculated