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

Mark Lawrence breamoreboy at yahoo.co.uk
Fri Jan 17 16:15:58 CET 2014


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?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence



More information about the Python-Dev mailing list