[Python-checkins] peps: fixed foot-notes; added %b and clarified %s as a synonym for %b

Thu Mar 27 19:06:15 CET 2014

http://hg.python.org/peps/rev/c73784a49b33
changeset: 5438:c73784a49b33
user: Ethan Furman <ethan at stoneleaf.us>
date: Thu Mar 27 11:06:08 2014 -0700
summary:
 fixed foot-notes; added %b and clarified %s as a synonym for %b
files:
 pep-0461.txt | 33 ++++++++++++++++++++-------------
 1 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/pep-0461.txt b/pep-0461.txt
--- a/pep-0461.txt
+++ b/pep-0461.txt
@@ -94,14 +94,22 @@
 ``format`` numerics (binary), and 2) it will make 2/3 code easier as Python 2.x
 code uses ``%s``; however, it is restricted in what it will accept:
 
- - input type supports ``Py_buffer`` [6]_?
+ - input type supports ``Py_buffer`` [4]_?
 use it to collect the necessary bytes
 
 - input type is something else?
- use its ``__bytes__`` method [7]_ ; if there isn't one, raise a ``TypeError``
+ use its ``__bytes__`` method [5]_ ; if there isn't one, raise a ``TypeError``
 
-In particular, ``%s`` will not accept numbers (use a numeric format code for
-that), nor ``str`` (encode it to ``bytes``).
+In particular, ``%s`` will not accept numbers nor ``str``. ``str`` is rejected
+as the string to bytes conversion requires an encoding, and we are refusing to
+guess; numbers are rejected because:
+
+ - what makes a number is fuzzy (float? Decimal? Fraction? some user type?)
+
+ - allowing numbers would lead to ambiguity between numbers and textual
+ representations of numbers (3.14 vs '3.14')
+
+ - given the nature of wire formats, explicit is definitely better than implicit
 
 Examples::
 
@@ -128,7 +136,7 @@
 into the stream; debugging data going into an existing protocol to see if
 the problem is the protocol itself or bad data; a fall-back for a serialization
 format; or any situation where defining ``__bytes__`` would not be appropriate
-but a readable/informative representation is needed [8]_.
+but a readable/informative representation is needed [6]_.
 
 Examples::
 
@@ -178,17 +186,18 @@
 ``__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]_,
+A competing PEP, ``PEP 460 Add binary interpolation and formatting`` [7]_,
 also exists.
 
 
 Objections
 ==========
 
-The objections raised against this PEP were mainly variations on two themes::
+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
@@ -213,13 +222,11 @@
 .. [1] http://docs.python.org/2/library/stdtypes.html#string-formatting
 .. [2] neither string.Template, format, nor str.format are under consideration
 .. [3] https://mail.python.org/pipermail/python-dev/2014-January/131518.html
-.. [4] to use a str object in a bytes interpolation, encode it first
-.. [5] %c is not an exception as neither of its possible arguments are str
-.. [6] http://docs.python.org/3/c-api/buffer.html
+.. [4] 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] https://mail.python.org/pipermail/python-dev/2014-February/132750.html
-.. [9] http://python.org/dev/peps/pep-0460/
+.. [5] http://docs.python.org/3/reference/datamodel.html#object.__bytes__
+.. [6] https://mail.python.org/pipermail/python-dev/2014-February/132750.html
+.. [7] http://python.org/dev/peps/pep-0460/
 
 
 Copyright
-- 
Repository URL: http://hg.python.org/peps
