[Python-checkins] peps: added Objections section; fixed formatting

[ethan.furman]

http://hg.python.org/peps/rev/fddeb948a6a3
changeset:   5383:fddeb948a6a3
user:        Ethan Furman <ethan at stoneleaf.us>
date:        Sat Feb 22 18:41:14 2014 -0800
summary:
  added Objections section; fixed formatting

files:
  pep-0461.txt |  33 ++++++++++++++++++++++++++++-----
  1 files changed, 28 insertions(+), 5 deletions(-)


diff --git a/pep-0461.txt b/pep-0461.txt
--- a/pep-0461.txt
+++ b/pep-0461.txt
@@ -45,7 +45,7 @@
 =====================
 
 In order to avoid the problems of auto-conversion and Unicode exceptions
-that could plague Python 2 code, :class:`str` objects will not be supported as
+that could plague Python 2 code, ``str`` objects will not be supported as
 interpolation values [4]_ [5]_.
 
 
@@ -73,7 +73,7 @@
 ``%c`` will insert a single byte, either from an ``int`` in range(256), or from
 a ``bytes`` argument of length 1, not from a ``str``.
 
-Example:
+Example::
 
     >>> b'%c' % 48
     b'0'
@@ -89,7 +89,7 @@
   - input type is something else?
     use its ``__bytes__`` method [7]_ ; if there isn't one, raise a ``TypeError``
 
-Examples:
+Examples::
 
     >>> b'%s' % b'abc'
     b'abc'
@@ -113,7 +113,7 @@
 
       'a string'.encode('latin-1')
 
-``%a`` will call :func:``ascii()`` on the interpolated value's :func:``repr()``.
+``%a`` will call ``ascii()`` on the interpolated value's ``repr()``.
 This is intended as a debugging aid, rather than something that should be used
 in production.  Non-ascii values will be encoded to either ``\xnn`` or ``\unnnn``
 representation.
@@ -122,7 +122,7 @@
 Unsupported codes
 -----------------
 
-``%r`` (which calls ``__repr__`` and returns a :class:`str`) is not supported.
+``%r`` (which calls ``__repr__`` and returns a '`str`') is not supported.
 
 
 Proposed variations
@@ -153,6 +153,27 @@
 be visited again later if real-world use shows deficiencies with this solution.
 
 
+Objections
+==========
+
+The objections raised against this PEP were mainly variations on two themes::
+
+  - the ``bytes`` and ``bytearray`` types are for pure binary data, with no
+    assumptions about encodings
+  - offering %-interpolation that assumes an ASCII encoding will be an
+    attractive nuisance and lead us back to the problems of the Python 2
+    ``str``/``unicode`` text model
+
+As was seen during the discussion, ``bytes`` and ``bytearray`` are also used
+for mixed binary data and ASCII-compatible segments: file formats such as
+``dbf`` and ``pdf``, network protocols such as ``ftp`` and ``email``, etc.
+
+``bytes`` and ``bytearray`` already have several methods which assume an ASCII
+compatible encoding.  ``upper()``, ``isalpha()``, and ``expandtabs()`` to name
+just a few.  %-interpolation, with its very restricted mini-language, will not
+be any more of a nuisance than the already existing methdods.
+
+
 Open Questions
 ==============
 
@@ -176,6 +197,8 @@
 .. [6] http://docs.python.org/3/c-api/buffer.html
        examples:  ``memoryview``, ``array.array``, ``bytearray``, ``bytes``
 .. [7] http://docs.python.org/3/reference/datamodel.html#object.__bytes__
+.. [8] mainly implicit encode/decode, with intermittent errors when the data
+       was not ASCII compatible
 
 
 Copyright

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