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.
_______________________________________________
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
