[Python-Dev] format, int, and IntEnum

[Eli Bendersky]

On Thu, Aug 15, 2013 at 8:15 AM, Eric V. Smith <eric at trueblade.com> wrote:

> On Aug 15, 2013, at 10:59 AM, Eli Bendersky <eliben at gmail.com> wrote:
>
>
>
>
> On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith <eric at trueblade.com> wrote:
>
>> On 8/15/2013 12:27 AM, Nick Coghlan wrote:
>> > I think Eric is overinterpreting the spec, there. While that particular
>> > sentence requires that the empty format string will be equivalent to a
>> > plain str() operation for builtin types, it is only a recommendation for
>> > other types. For enums, I believe they should be formatted like their
>> > base types (so !s and !r will show the enum name, anything without
>> > coercion will show the value) .
>>
>> I don't think I'm over-interpreting the spec (but of course I'd say
>> that!). The spec is very precise on the meaning of "format specifier":
>> it means the entire string (the second argument to __format__). I'll
>> grant that in the sentence in question it uses "format specification",
>> not "format specifier", though.
>>
>> I think this interpretation also meshes with builtin-in "format": with
>> no format_spec argument, it uses an zero-length string as the default
>> specifically to get the str(obj) behavior.
>>
>> Using bool as an example because it's easier to type:
>>
>> >>> format(True)
>> 'True'
>> >>> format(True, '10')
>> '         1'
>>
>>
> Eric, which-ever way you interpret the spec, the above violates the
> least-surprise principle; do you agree? It's easily one of those things
> that makes the "WTF, Python?" lists. Do you disagree?
>
>
> Oh, I completely agree that it doesn't make much sense, and is surprising.
> I was just trying to explain why we see the current behavior.
>
> Unfortunately, I don't think there's a lot we can do about it now. It's a
> design mistake, locked with backwards compatibility until "Python 4".
>
>
> Agreed.
>
> For IntEnum, being in control of __format__ and being a new class, I
> suppose we can create any behavior we want here.
>
>
> Right. That's the intent. I'd personally be okay with checking for int
> format codes (bdxX, etc.) and treating it as an int, otherwise a string. As
> I've pointed out, it's slightly fragile, and there are a few cases where a
> valid int format spec will give an error when treating it as a string, but
> that doesn't bother me.
>

This got me thinking when we were discussing it in the issue. It's
plausible that every subclass of builtin types will need to implement
__format__ to act sanely. So maybe we can propose some sort of API (on the
Python level) that makes parsing the format string easy and will not make
code go stale? What do you think?


> Can we do more? Is it even conceivable to rig the boolean sub-type to
> change this behavior to be more rational? I suspect that no, but one can
> hope ;-)
>
>
> I don't think there's much we can do, unfortunately. I think bool should
> work the same as the proposed IntEnum changes, but that's an incompatible
> change.
>

:-(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130815/bc537df4/attachment.html>