typo, spelling, caps

pep-3140.txt

@@ -3,7 +3,7 @@ Title: str(container) should call str(item), not repr(item)
 Version: $Revision$
 Last-Modified: $Date: 2008-05-28 20:38:33 -0600 (Thu, 28 May 2008)$
 Author: Oleg Broytmann <phd@phd.pp.ru>,
-       Jim Jewett <jimjjewett@gmail.com>
+        Jim Jewett <jimjjewett@gmail.com>
 Discussions-To: python-3000@python.org
 Status: Rejected
 Type: Standards Track
@@ -40,7 +40,7 @@ Motivation
    -- 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 @@ Current situation
 
    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 @@ Current situation
    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 @@ A different approach - call str(item)
    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.