added list of currently supported codes; modified description for %a; added reference to competing PEP 460

pep-0461.txt

@@ -50,11 +50,17 @@ Proposed semantics for ``bytes`` and ``bytearray`` formatting
 %-interpolation
 ---------------
 
-All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
+All the numeric formatting codes (``d``, ``i``, ``o``, ``u``, ``x``, ``X``,
-``%g``, etc.) will be supported, and will work as they do for str, including
+``e``, ``E'', ``f``, ``F``, ``g``, ``G``, and any that are subsequently added
-the padding, justification and other related modifiers.  The only difference
+to Python 3) will be supported, and will work as they do for str, including
-will be that the results from these codes will be ASCII-encoded text, not
+the padding, justification and other related modifiers (currently ``#``, ``0``,
-unicode.  In other words, for any numeric formatting code `%x`::
+``-``, `` `` (space), and ``+`` (plus any added to Python 3)).  The only
+non-numeric codes allowed are ``c``, ``s``, and ``a``.
+
+For the numeric codes, the only difference between ``str`` and ``bytes`` (or
+``bytearray``) interpolation is that the results from these codes will be
+ASCII-encoded text, not unicode.  In other words, for any numeric formatting
+code `%x`::
 
    b"%x" % val
 
@@ -116,18 +122,24 @@ Examples::
     TypeError: b'%s' does not accept 'str', it must be encoded to `bytes`
 
 
-``%a`` will call ``ascii()`` on the interpolated value.  This is intended
+``%a`` will give the equivalent of
-as a debugging aid, rather than something that should be used in production.
+``repr(some_obj).encode('ascii', 'backslashreplace')`` on the interpolated
-Non-ASCII values will be encoded to either ``\xnn`` or ``\unnnn``
+value.  Use cases include developing a new protocol and writing landmarks
-representation.  Use cases include developing a new protocol and writing
+into the stream; debugging data going into an existing protocol to see if
-landmarks into the stream; debugging data going into an existing protocol
+the problem is the protocol itself or bad data; a fall-back for a serialization
-to see if the problem is the protocol itself or bad data; a fall-back for a
+format; or any situation where defining ``__bytes__`` would not be appropriate
-serialization format; or even a rudimentary serialization format when
+but a readable/informative representation is needed [8].
-defining ``__bytes__`` would not be appropriate [8].
 
-.. note::
+Examples::
 
-    If a ``str`` is passed into ``%a``, it will be surrounded by quotes.
+    >>> b'%a' % 3.14
+    b'3.14'
+
+    >>> b'%a' % b'abc'
+    b'abc'
+
+    >>> b'%a' % 'def'
+    b"'def'"
 
 
 Unsupported codes
@@ -166,6 +178,9 @@ Various new special methods were proposed, such as ``__ascii__``,
 ``__format_bytes__``, etc.; such methods are not needed at this time, but can
 be visited again later if real-world use shows deficiencies with this solution.
 
+A competing PEP, ``PEP 460 Add binary interpolation and formatting`` [9], also
+exists.
+
 
 Objections
 ==========
@@ -204,6 +219,7 @@ Footnotes
        examples:  ``memoryview``, ``array.array``, ``bytearray``, ``bytes``
 .. [7] http://docs.python.org/3/reference/datamodel.html#object.__bytes__
 .. [8] https://mail.python.org/pipermail/python-dev/2014-February/132750.html
+.. [9] http://python.org/dev/peps/pep-0460/
 
 
 Copyright