[Python-Dev] str(IntEnum)

[Guido van Rossum]

On Sat, Feb 21, 2015 at 8:39 AM, Demian Brecht <demianbrecht at gmail.com>
wrote:

> >
> > On Feb 20, 2015, at 7:03 PM, Ian Cordasco <graffatcolmingov at gmail.com>
> wrote:
> > I hope this helps.
>
> It does, as do the other replies, thanks all. To be clear, my first gripe
> has stemmed into two related (but very minor) problems:
>
> 1. IntEnum.__str__. I understand the reasoning behind the current
> implementation. Personally I’d still prefer it to be consistent with int
> (and other types as shown above) and if I wanted to know where it came
> from, I could use repr(), but I understand that this /was/ previously
> thought out and is contrary to the decision made. I’m fine with being in
> the minority (or on my own as it seems in this case) and leaving it alone
> (with the only caveat being the next point).
>

You are indeed very much out of sync here. There is no requirement or even
convention that int subclasses have the same str() as plain ints -- in fact
a custom str() is a common reason. For example, it's one of the reasons why
I eventually caved in and added bool to the language. People want the
custom representation used when they say print(x), they don't want to have
to say print(repr(x)).


> 2. Consistency of __str__ semantics across the standard library and
> builtins. I believe that the value of __str__ is something that I, as a
> user, should be able to infer when using disparate types. Unfortunately,
> some represent the values while other represent the object themselves,
> nearly the same problem that __repr__ solves minus the requirement of being
> a valid Python expression where possible. In my mind, a clear separation
> between __str__ representing the value of an instance and __repr__
> representing the object, or where the value came from (and perhaps /not/
> having the auto-fallback) makes sense, but would only be one potential
> solution to promoting consistency.
>

Again, this is an area where you are on your own looking for consistency.
str() is what print() uses (by mutual definition) and print() should print
whatever is the most useful as the default for a given use case. There is
*no* rule that says a subclass cannot change the str().


> In any event, there are many larger problems to be solved (that is, if
> anyone else /does/ consider this a problem) and I very well may be on my
> own with this thinking.
>

It sure seems that way.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150224/432bec4b/attachment.html>