On Thu, Aug 15, 2013 at 3:03 AM, Eric V. Smith <e...@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? 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". For IntEnum, being in control of __format__ and being a new class, I suppose we can create any behavior we want here. 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 ;-) 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. Eli
_______________________________________________ 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