[Python-Dev] PEP 461 - Adding % and {} formatting to bytes

[Eric V. Smith]

On 01/17/2014 10:15 AM, Mark Lawrence wrote:
> On 17/01/2014 14:50, Eric V. Smith wrote:
>> On 01/17/2014 07:34 AM, Eric V. Smith wrote:
>>> On 1/17/2014 6:42 AM, Nick Coghlan wrote:
>>>>
>>>> On 17 Jan 2014 18:03, "Eric Snow" <ericsnowcurrently at gmail.com
>>>> <mailto:ericsnowcurrently at gmail.com>> wrote:
>>>>>
>>>>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith <eric at trueblade.com
>>>> <mailto:eric at trueblade.com>> wrote:
>>>>>> For the first iteration of bytes.format(), I think we should just
>>>>>> support the exact types of int, float, and bytes. It will call the
>>>>>> type's__format__ (with the object as "self") and encode the result to
>>>>>> ASCII. For the stated use case of 2.x compatibility, I suspect
>>>>>> this will
>>>>>> cover > 90% of the uses in real code. If we find there are cases
>>>>>> where
>>>>>> real code needs additional types supported, we can consider adding
>>>>>> __format_ascii__ (or whatever name we cook up).
>>>>>
>>>>> +1
>>>>
>>>> Please don't make me learn the limitations of a new mini language
>>>> without a really good reason.
>>>>
>>>> For the sake of argument, assume we have a Python 3.5 with
>>>> bytes.__mod__
>>>> restored roughly as described in PEP 461. *Given* that feature set,
>>>> what
>>>> is the rationale for *adding* bytes.format? What new capabilities will
>>>> it provide that aren't already covered by printf-style interpolation
>>>> directly to bytes or text formatting followed by encoding the result?
>>>
>>> The only reason to add any of this, in my mind, is to ease porting of
>>> 2.x code. If my proposal covers most of the cases of b''.format() that
>>> exist in 2.x code that wants to move to 3.5, then I think it's worth
>>> doing. Is there any such code that's blocked from porting by the lack of
>>> b''.format() that supports bytes, int, and float? I don't know. I
>>> concede that it's unlikely.
>>>
>>> IF this were a feature that we were going to add to 3.5 on its own
>>> merits, I think we add __format_ascii__ and make the whole thing
>>> extensible. Is there any new code that's blocked from being written by
>>> missing b"".format()? I don't know that, either.
>>
>> Following up, I think this leaves us with 3 choices:
>>
>> 1. Do not implement bytes.format(). We tell any 2.x code that's written
>> to use str.format() to switch to %-formatting for their common code base.
>>
>> 2. Add the simplistic version of bytes.format() that I describe above,
>> restricted to accepting bytes, int, and float (and no subclasses). Some
>> 2.x code will work, some will need to change to %-formatting.
>>
>> 3. Add bytes.format() and the __format_ascii__ protocol. We might want
>> to also add a format_ascii() builtin, to match __format__ and format().
>> This would require the least change to 2.x code that uses str.format()
>> and wants to move to bytes.format(), but would require some work on the
>> 3.x side.
>>
>> I'd advocate 1 or 2.
>>
>> Eric.
>>
> 
> For both options 1 and 2 surely you cannot be suggesting that after
> people have written 2.x code to use format() as %f formatting is to be
> deprecated, they now have to change the code back to the way they may
> well have written it in the first place?
> 

That would be part of it, yes. Otherwise you need #3.

This is all assuming we've ruled out an option 4, because of the
exceptions raised depending on what __format__ does:

4. Add bytes.format(), have it convert the format specifier to str
(unicode), call __format__ and encode the result back to ASCII. Accept
that there will be data-driven exceptions depending on the result of the
__format__ call.

I'm open to other ideas.

Eric.