On 01/16/2014 10:30 AM, Eric V. Smith wrote:
On 01/16/2014 11:23 AM, Ethan Furman wrote:
On 01/16/2014 06:45 AM, Brett Cannon wrote:
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.
Yes, that's why I said `myNum(17)` and not `myNum`.
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).
That can certainly be our fallback position if we can't decide now how we want
to handle int and float subclasses.
--
~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
