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

Sun Jun 1 16:30:25 CEST 2008

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 (2008年5月28日)$
 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.
