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