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

Ethan Furman ethan at stoneleaf.us
Thu Jan 16 17:23:13 CET 2014


On 01/16/2014 06:45 AM, Brett Cannon wrote:
> On Thu, Jan 16, 2014 at 2:51 AM, Ethan Furman wrote:
>> On 01/15/2014 06:45 AM, Brett Cannon wrote:
>>>
>>> This is why I have argued that if you specify it as
>>>  "if there is a format spec specified, then the return
>>> value from calling __format__() will have
>>>  str.decode('ascii', 'strict') called on it" you get
>>> the support for the various number-specific format
>>>  specs for free.

>> Since the numeric format codes will call int, index,
>>  or float on the object (to handle subclasses),
>
> But that's **only** because the numeric types choose
>  to as part of their __format__() implementation; it is
> not inherent to str.format().

As I understand it, str.format will call the object's __format__.  So, for example, if I say:

   u'the value is: %d' % myNum(17)

then it will be myNum.__format__ that gets called, not int.__format__; this is precisely what we don't want, since can't 
know that myNum is only going to return ASCII characters.

This is why I would have bytes.__format__, as part of its parsing, call int, index, or float depending on the format 
code; so the above example would have bytes.__format__ calling int() on myNum(17), at which point we either have an int 
type or an exception was raised because myNum isn't really an integer.  Once we have an int, whose format we know and 
trust, then we can call its __format__ and proceed from there.

On the flip side, if myNum does define it's own __format__, it will not be called by bytes.format, and perhaps that is 
another good reason for bytes to only support %-interpolation and not format?

--
~Ethan~


More information about the Python-Dev mailing list