On Aug 15, 2013, at 10:59 AM, Eli Bendersky <eli...@gmail.com> wrote:
> > > > 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? 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.
_______________________________________________ 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
