Nick Coghlan added the comment: 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. ---------- resolution: -> rejected stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17961> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
