[Python-Dev] PEP 435 - ref impl disc 2 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun May 5 10:08:36 CEST 2013

On Sun, May 5, 2013 at 5:21 PM, Ethan Furman <ethan at 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 | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list