[Python-Dev] PEP 461 - Adding % and {} formatting to bytes (original) (raw)

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

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

Eric.

More information about the Python-Dev mailing list