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

Eric V. Smith eric at trueblade.com
Thu Jan 16 19:30:01 CET 2014

On 01/16/2014 11:23 AM, Ethan Furman wrote:
> 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.

"Magic" methods, including __format__, are called on the type, not the

> 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?

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).


More information about the Python-Dev mailing list