Eric V. Smith added the comment:
>> In order to avoid that logic, and cause more format specifiers to result in
>> str-like behavior, we'll need to implement an __format__ somewhere (IntEnum,
>> I guess) that makes the "int or str" decision.
>
> If this is the way format is supposed to work, then I'll add __format__ to
> IntEnum with simple logic that says if not
> letter format code is present, use string formatting, otherwise use int
> formatting.
Yes, that's exactly how it's supposed to be used, and why __format__
exists at all.
> That should be future proof.
Agreed.
It does mean that a few things that look like int format specifiers
won't be, but I don't think it's a big loss.
For example, '+' only makes sense on an int, but with your proposal it
would be a str format specifier:
>>> format(42, '+')
'+42'
>>> format('42', '+')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: Sign not allowed in string format specifier
Again, I don't think any of these would be a big deal. But it does mean
that there are places that could take an int that can't take an IntEnum.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18738>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
