Thanks Ethan, this mostly looks excellent. On 23 February 2014 11:56, Ethan Furman <ethan at stoneleaf.us> wrote: > ``%a`` will call :func:``ascii()`` on the interpolated value's > :func:``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. Is this really what is intended? It seems to me that what is needed is to just call ascii(), which is inherently based on repr(): >>> ascii(1) '1' >>> ascii("1") "'1'" >>> ascii(b"1") "b'1'" The current wording in the PEP effectively suggests invoking repr() twice, which is just weird: >>> ascii(repr(1)) "'1'" >>> ascii(repr("1")) '"\'1\'"' >>> ascii(repr(b"1")) '"b\'1\'"' And inconsistent with the meaning of %a in text interpolation: >>> ("%a" % 1).encode("ascii") b'1' > Open Questions > ============== > > It has been suggested to use ``%b`` for bytes as well as ``%s``. > > - Pro: clearly says 'this is bytes'; should be used for new code. > > - Con: does not exist in Python 2.x, so we would have two ways of doing > the > same thing, ``%s`` and ``%b``, with no difference between them. Another con is that using %b this way would be inconsistent with the "b" numeric format code that requests binary output: >>> format(2, "b") '10' >>> format(2, "#b") '0b10' So -1 for "%b" from me on both TOOWTDI and consistency grounds. Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4