On 05/05/2013 01:08 AM, Nick Coghlan wrote:
On Sun, May 5, 2013 at 5:21 PM, Ethan Furman <et...@stoneleaf.us> wrote:
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__")
Certainly the docs need to be clear about this. I don't think the PEP needs to be. (Apologies if you were not
referring to the PEP.)
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.
Fair point -- working on it.
--
~Ethan~
_______________________________________________
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
