> > On Feb 20, 2015, at 7:03 PM, Ian Cordasco <graffatcolmin...@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). 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. 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
