[Python-Dev] format, int, and IntEnum

[Eric V. Smith]

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.  

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

> And in any case, the documentation has to be tightened a bit formally to express what we mean exactly, how it translates to the behavior of builtin types, and what is allowed for custom types.

I'm okay with that. 

Eric.

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