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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
