[Python-checkins] r63852 - peps/trunk/pep-3140.txt

[david.goodger]

Author: david.goodger
Date: Sun Jun  1 16:30:24 2008
New Revision: 63852

Log:
typo, spelling, caps

Modified:
   peps/trunk/pep-3140.txt

Modified: peps/trunk/pep-3140.txt
==============================================================================
--- peps/trunk/pep-3140.txt	(original)
+++ peps/trunk/pep-3140.txt	Sun Jun  1 16:30:24 2008
@@ -3,7 +3,7 @@
 Version: $Revision$
 Last-Modified: $Date: 2008-05-28 20:38:33 -0600 (Thu, 28 May 2008)$
 Author: Oleg Broytmann <phd at phd.pp.ru>,
-       Jim Jewett <jimjjewett at gmail.com>
+        Jim Jewett <jimjjewett at gmail.com>
 Discussions-To: python-3000 at python.org
 Status: Rejected
 Type: Standards Track
@@ -40,7 +40,7 @@
    -- there is no standard way to print a container's content calling
       items' __str__, that's inconvenient in cases where __str__ and
       __repr__ return different results;
-   -- repr(item) sometimes do wrong things (hex-escapes non-ascii
+   -- repr(item) sometimes do wrong things (hex-escapes non-ASCII
       strings, e.g.)
 
    This PEP proposes to change how str(container) works.  It is
@@ -69,14 +69,14 @@
 
    The disadvantage is that __repr__ often returns technical data
    (like '<object at address>') or unreadable string (hex-encoded
-   string if the input is non-ascii string):
+   string if the input is non-ASCII string):
 
        >>> print(['тест'])
        ['\xd4\xc5\xd3\xd4']
 
    One of the motivations for PEP 3138 is that neither repr nor str
-   will allow the sensible printing of dicts whose keys are non-ascii
-   text strings.  Now that unicode identifiers are allowed, it
+   will allow the sensible printing of dicts whose keys are non-ASCII
+   text strings.  Now that Unicode identifiers are allowed, it
    includes Python's own attribute dicts.  This also includes JSON
    serialization (and caused some hoops for the json lib).
 
@@ -85,7 +85,7 @@
    persistence) outputs some objects, with system-dependent failures.
 
    Changing how str(container) works would allow easy debugging in
-   the normal case, and retrain the safety of ASCII-only for the
+   the normal case, and retain the safety of ASCII-only for the
    machine-readable  case.  The only downside is that str(x) and
    repr(x) would more often be different -- but only in those cases
    where the current almost-the-same version is insufficient.
@@ -169,9 +169,9 @@
    drawback of the proposal is that every __repr__ implementation
    must be changed.  Introspection could help a bit (inspect __repr__
    before calling if it accepts 2 or 3 parameters), but introspection
-   doesn't work on classes written in C, like all builtin containers.
+   doesn't work on classes written in C, like all built-in containers.
 
-   Less radical proposal is to implement __str__ methods for builtin
+   Less radical proposal is to implement __str__ methods for built-in
    container types.  The obvious drawback is a duplication of effort
    - all those __str__ and __repr__ implementations are only differ
    in one small detail - if they call str or repr on items.