[Python-Dev] format, int, and IntEnum

[Eric V. Smith]

On Aug 15, 2013, at 11:36 AM, Eli Bendersky <eliben at gmail.com> wrote:

> 
> 
> 
> 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?

I've proposed this in the past, primarily for Decimal. I'd be okay with it. It would need to done carefully to allow us to expand the format string, for example when we added ','. Maybe return a namedtuple or equivalent. 

But remember, not all types understand the same format strings. datetime being the classic case. 

> 
>> 
>>> 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. 
> 
> :-(

I know. Me, too. 

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