[Python-checkins] peps: Latest update from Eric

[barry.warsaw]

http://hg.python.org/peps/rev/b9919c6057ca
changeset:   4380:b9919c6057ca
user:        Barry Warsaw <barry at python.org>
date:        Tue May 15 11:04:25 2012 -0400
summary:
  Latest update from Eric

files:
  pep-0421.txt |  61 +++++++++++++++++++++------------------
  1 files changed, 33 insertions(+), 28 deletions(-)


diff --git a/pep-0421.txt b/pep-0421.txt
--- a/pep-0421.txt
+++ b/pep-0421.txt
@@ -34,7 +34,7 @@
 viable alternate implementations of Python.
 
 Consider, however, the nearly two decades of CPython-centric Python
-(i.e. most of its existence).  That focus had understandably
+(i.e. most of its existence).  That focus has understandably
 contributed to quite a few CPython-specific artifacts both in the
 standard library and exposed in the interpreter.  Though the core
 developers have made an effort in recent years to address this, quite
@@ -60,7 +60,7 @@
 ensures behaviors don't change between versions which depend on
 attributes of ``sys.implementation``.
 
-The object will have each of the attributes described in the `Required
+The object has each of the attributes described in the `Required
 Attributes`_ section below.  Those attribute names will never start
 with an underscore.  The standard library and the language definition
 will rely only on those required attributes.
@@ -114,9 +114,9 @@
 specification.
 
 All proposals for new required attributes will go through the normal
-PEP process.  Such a PEP need not be all that long, but will need to
-sufficiently spell out the rationale for the new attribute, its use
-cases, and the impact it will have on the various Python
+PEP process.  Such a PEP need not be long, just long enough.  It will
+need to sufficiently spell out the rationale for the new attribute,
+its use cases, and the impact it will have on the various Python
 implemenations.
 
 
@@ -153,13 +153,13 @@
 It's very easy to get bogged down in discussions about the type of
 ``sys.implementation``.  However, its purpose is to support the
 standard library and language definition.  As such, there isn't much
-that really matters in this regard, as opposed to a feature that would
-be more generally used.  Thus characteristics like immutability and
-sequence-ness have been disregarded.
+that really matters regarding its type, as opposed to a feature that
+would be more generally used.  Thus characteristics like immutability
+and sequence-ness have been disregarded.
 
-The only real choice was between an object with attribute access and a
-mapping with item access.  This PEP espouses dotted access to reflect
-the relatively fixed nature of the namespace.
+The only real choice has been between an object with attribute access
+and a mapping with item access.  This PEP espouses dotted access to
+reflect the relatively fixed nature of the namespace.
 
 
 Non-Required Attributes
@@ -179,8 +179,8 @@
 Why a Part of ``sys``?
 ----------------------
 
-The ``sys`` module should hold the new namespace because ``sys`` is
-the depot for interpreter-centric variables and functions.  Many
+The ``sys`` module holds the new namespace because ``sys`` is the depot
+for interpreter-centric variables and functions.  Many
 implementation-specific attributes are already found in ``sys``.
 
 
@@ -191,8 +191,8 @@
 ``sys.implementation`` are intended for use by the standard library.
 Constraining those values, essentially specifying an API for them,
 allows them to be used consistently, regardless of how they are
-otherwise implemented.  However, care should be take to not over-
-specify the constraints.
+otherwise implemented.  However, care should be take to not
+over-specify the constraints.
 
 
 Discussion
@@ -204,7 +204,7 @@
 ``imp.get_tag()`` [#revived]_.  Discussion has been ongoing
 [#feedback]_.  The messages in `issue #14673`_ are also relevant.
 
-A good part of the discussion centered on the type to use for
+A good part of the recent discussion centered on the type to use for
 ``sys.implementation``.
 
 
@@ -228,7 +228,7 @@
 module.
 
 Another concern is that the ``platform`` module is part of the stdlib,
-which ideally would minimize implementation details such as would be
+which ideally should minimize implementation details such as would be
 moved to ``sys.implementation``.
 
 Any overlap between ``sys.implementation`` and the ``platform`` module
@@ -301,7 +301,7 @@
 
 As Barry Warsaw noted, the "semantics of sys.version_info have been
 sufficiently squishy in the past" [#Barry]_.  With
-``sys.implementation`` we have the opportunity to improving the
+``sys.implementation`` we have the opportunity to improve this
 situation by first establishing an explicit location for the version of
 the implementation.
 
@@ -320,7 +320,8 @@
 Jeff Hardy responded to a request for feedback [#ironpython]_.  He
 said, "I'll probably add it the day after it's approved"
 [#jeff_hardy_2012]_.  He also gave useful feedback on both the type of
-``sys.implementation`` and on the ``metadata`` attribute.
+``sys.implementation`` and on the ``metadata`` attribute (which has
+since been removed from the PEP).
 
 Jython
 ------
@@ -349,22 +350,22 @@
 Past Efforts
 ============
 
-PEP 3139
---------
+``PEP 3139``
+------------
 
-This PEP from 2008 recommended a clean-up of the ``sys`` module in
+PEP 3139, from 2008, recommended a clean-up of the ``sys`` module in
 part by extracting implementation-specific variables and functions
 into a separate module.  PEP 421 is less ambitious version of that
 idea.  While PEP 3139 was rejected, its goals are reflected in PEP 421
 to a large extent, though with a much lighter approach.
 
 
-PEP 399
--------
+``PEP 399``
+-----------
 
-This informational PEP dictates policy regarding the standard library,
-helping to make it friendlier to alternate implementations.  PEP 421
-is proposed in that same spirit.
+PEP 399 dictates policy regarding the standard library, helping to make
+it friendlier to alternate implementations.  PEP 421 is proposed in
+that same spirit.
 
 
 The Bigger Picture
@@ -372,7 +373,7 @@
 
 It's worth noting again that this PEP is a small part of a larger
 on-going effort to identify the implementation-specific parts of Python
-and mitigate their impact on other implementations than CPython.
+and mitigate their impact on alternate implementations.
 
 ``sys.implementation`` is a focal point for implementation-specific
 data, acting as a nexus for cooperation between the language, the
@@ -398,8 +399,10 @@
 Examples of Other Attributes
 ============================
 
-These are examples only and not part of the proposal.  (See `Adding
-New Required Attributes`_ if they get you excited.)
+These are examples only and not part of the proposal.  Most of them
+were suggested during previous discussions, but did not fit into the
+goals of this PEP.  (See `Adding New Required Attributes`_ if they get
+you excited.)
 
 **common_name**
    The case-sensitive name by which the implementation is known.

-- 
Repository URL: http://hg.python.org/peps