[Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Nick Coghlan]

On 25 February 2014 17:43, Stuart Bishop <stuart at stuartbishop.net> wrote:
> On 23 February 2014 08: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.
>
> So we use %a for exactly the same purposes that we used to use %r.
>
>> Unsupported codes
>> -----------------
>>
>> ``%r`` (which calls ``__repr__`` and returns a :class:`str`) is not
>> supported.
>
> But you propose changing the code.
>
> I think there would have been a lot less discussion if you just
> defined %r to do what you propose for %a, as everything would work as
> people expected.

No, it wouldn't.

[Python 3]
>>> "%r" % "\xe9"
"'é'"
>>> "%a" % "\xe9"
"'\\xe9'"

%r is being disallowed in PEP 461 because it doesn't guarantee ASCII
compatibility in Python 3 the way it did in Python 2. That's not up
for discussion, as having %r behave like %a in binary interpolation
but not in text interpolation would be far too confusing.

However, %a *already* guarantees ASCII compatible output for text
interpolation (by escaping everything below 0x20 or above 0x7F, the
same way %r did in Python 2), so some of us think %a *should* be
allowed for consistency with text interpolation, both because there's
no compelling reason to disallow it and because it's the obvious way
to interpolate representations of arbitrary objects into binary
formats that contain ASCII compatible segments.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia