iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Make it clear that the objection headings are paraphrased versions of the complaints made about the PEP

This commit is contained in:
Nick Coghlan 2012-03-04 17:48:49 +10:00
parent 6f949e069a
commit 9f04df4927
1 changed files with 11 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
pep-0414.txt
View File

@ -119,8 +119,8 @@ Common Objections
=================
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 @@ If such an import hook becomes available, this PEP will be updated to include
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 @@ This point is further reinforced by the fact that Python 3 *still* allows the
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 @@ normal deprecation process, support for redundant string prefix characters
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 @@ helper functions), they can be expressed as:
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,