[Python-checkins] peps: Make it clear that the objection headings are paraphrased versions of the

[nick.coghlan]

http://hg.python.org/peps/rev/dd45be81d861
changeset:   4107:dd45be81d861
user:        Nick Coghlan <ncoghlan at gmail.com>
date:        Sun Mar 04 17:48:49 2012 +1000
summary:
  Make it clear that the objection headings are paraphrased versions of the complaints made about the PEP

files:
  pep-0414.txt |  17 +++++++++++------
  1 files changed, 11 insertions(+), 6 deletions(-)


diff --git a/pep-0414.txt b/pep-0414.txt
--- a/pep-0414.txt
+++ b/pep-0414.txt
@@ -119,8 +119,8 @@
 =================
 
 
-This PEP may harm adoption of Python 3.2
-----------------------------------------
+Complaint: This PEP may harm adoption of Python 3.2
+---------------------------------------------------
 
 This complaint is interesting, as it carries within it a tacit admission that
 this PEP *will* make it easier to port Unicode aware Python 2 applications to
@@ -147,8 +147,8 @@
 a reference to it.
 
 
-Python 3 shouldn't be made worse just to support porting from Python 2
-----------------------------------------------------------------------
+Complaint: Python 3 shouldn't be made worse just to support porting from Python 2
+---------------------------------------------------------------------------------
 
 This is indeed one of the key design principles of Python 3. However, one of
 the key design principles of Python as a whole is that "practicality beats
@@ -193,7 +193,7 @@
 uppercase variants of the ``B`` and ``R`` prefixes for bytes literals and raw
 bytes and string literals. If the potential for confusion due to string prefix
 variants is that significant, where was the outcry asking that these
-redundant prefixes removed along with all the other redundancies that were
+redundant prefixes be removed along with all the other redundancies that were
 eliminated in Python 3?
 
 Just as support for string exceptions was eliminated from Python 2 using the
@@ -202,8 +202,8 @@
 from Python 3, regardless of the current acceptance of this PEP.
 
 
-The WSGI "native strings" concept is an ugly hack, anyway
----------------------------------------------------------
+Complaint: The WSGI "native strings" concept is an ugly hack
+------------------------------------------------------------
 
 One reason the removal of unicode literals has provoked such concern amongst
 the web development community is that the updated WSGI specification had to
@@ -272,14 +272,15 @@
 That last approach is the only variant that supports Python 2.5 and earlier.
 
 Of all the alternatives, the format currently supported in Python 2.6 and 2.7
-is by far the cleanest. With this PEP, that format will also be supported in
+is by far the cleanest approach that clearly distinguishes the three desired
+kinds of behaviour. With this PEP, that format will also be supported in
 Python 3.3+. If the import hook approach works out as planned, it may even be
 supported in Python 3.1 and 3.2. A bit more effort could likely adapt the hook
 to allow the use of the ``b`` prefix on Python 2.5
 
 
-The existing tools should be good enough for everyone
------------------------------------------------------
+Complaint: The existing tools should be good enough for everyone
+----------------------------------------------------------------
 
 A commonly expressed sentiment from developers that have already sucessfully
 ported applications to Python 3 is along the lines of "if you think it's hard,

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