[Python-Dev] format, int, and IntEnum

[Ethan Furman]

 From http://bugs.python.org/issue18738:

Ethan Furman commented:
> --> class Test(enum.IntEnum):
> ...   one = 1
> ...   two = 2
> ...
>
> --> '{}'.format(Test.one)
> 'Test.one'
>
> --> '{:d}'.format(Test.one)
> '1'
>
> --> '{:}'.format(Test.one)
> 'Test.one'
>
> --> '{:10}'.format(Test.one)
> '         1'

Eric V. Smith commented:
> The value of int is always used, except when the format string is empty. PEP 3101 explicitly requires this behavior. "For all built-in types, an empty format specification will produce the equivalent of str(value)." The "built-in type" here refers to int, since IntEnum is derived from int (at least I think it is: I haven't followed the metaclass and multiple inheritance completely).

Ethan Furman commented:
> So what you're saying is that '{:}' is empty, but '{:10}' is not?

Eric V. Smith commented:
> Yes, exactly. The part before the colon says which argument to .format()
> to use. The empty string there means "use the next one". The part after the
> colon is the format specifier. In the first example above, there's an empty
> string after the colon, and in the second example there's a "10" after the
> colon.
>
> Which is why it's really easier to use:
> format(obj, '')
> and
> format(obj, '10')
> instead of .format examples. By using the built-in format, you only need
> to write the format specifier, not the ''.format() "which argument am I
> processing" stuff with the braces and colons.

Eli Bendersky commented:
> Eric, I'd have to disagree with this part. Placing strictly formal
> interpretation of "empty" aside, it seems to me unacceptable that
> field-width affects the interpretation of the string. This appears more
> like bug in the .format implementation than the original intention. I
> suspect that at this point it may be useful to take this discussion to
> pydev to get more opinions.