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~
_______________________________________________
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
