This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients barry, eli.bendersky, ethan.furman, ncoghlan, pitrou
Date 2013-06-19.11:32:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1371641522.02.0.726953835367.issue17961@psf.upfronthosting.co.za>
In-reply-to
Content
OK, I've satisfied myself that the current behaviour is reasonable, and it's specifically the subclassing behaviour of the status quo that works for me.

1. You have to specifically access the "x.value" attribute of a default enum member to see it. "str(x)" shows the fully qualified name, not the value (even for concrete subclasses).
2. The implicitly chosen values are valid for any concrete enum subclass that accepts a single integer as an argument. This covers strings and the whole numeric tower. The same can't be said for using the enum name.
3. The implicitly chosen values are always "true", even when used with a concrete numeric enum subclass. This matches the behaviour of standard user defined classes (where all instances are considered true by default unless you define __len__ or __bool__ to say otherwise).

The fact "str(x)" returns the fully qualified name for IntEnum worries me a bit, but if there's a real backwards compatibility problem there (rather than a theoretical one), hopefully we'll see it once we start converting socket and errno.
History
Date User Action Args
2013-06-19 11:32:02ncoghlansetrecipients: + ncoghlan, barry, pitrou, eli.bendersky, ethan.furman
2013-06-19 11:32:02ncoghlansetmessageid: <1371641522.02.0.726953835367.issue17961@psf.upfronthosting.co.za>
2013-06-19 11:32:02ncoghlanlinkissue17961 messages
2013-06-19 11:32:01ncoghlancreate