On Sun, May 5, 2013 at 5:21 PM, Ethan Furman <et...@stoneleaf.us> wrote: > When NamedInt goes looking for _name, it finds the one on `x`, not the one > on `x.value`.
There's also the code in enum_type.__call__ that ensures Enum.__repr__ and Enum.__str__ are used in preference to those from the value type. (Specifically, the code at https://bitbucket.org/stoneleaf/ref435/src/758d43b9f7327cd61dc2e45050539b6b5db1c4e3/ref435.py?at=default#cl-152 that ignores __repr__ and __str__ from non-Enum types) I think this needs to be documented more clearly - if you want to keep a custom __repr__ or __str__ when mixing Enum (or an Enum subclass) with another type, then you need to explicitly set them in your subclass. (e.g. in Glenn's case, setting "__repr__ = NamedValue.__repr__") I'm OK with magic to get the kind of enum behaviour we want, but I'm not OK with *black* magic that we don't explain. There should be an advanced section in the enum docs which explains these edge cases in the way the enum metaclass interacts with the normal class machinery. That said, I'm also fairly sure the current code is incorrect: I believe it does the wrong thing when an Enum subclass further customises __repr__, __str__ or __new__. The more reasonable logic to me seems to be to figure out the "first enum base" and the "first non-enum base" based on: enum_bases = [base for base in enum_class.mro() if issubclass(base, Enum)] non_enum_bases = [base for base in enum_class.mro() if not issubclass(base, Enum)] Then, if the current __new__, __str__ or __repr__ implementation is the same as that for the first non-enum base, we replace it with the impl from the first enum base. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
