[Python-Dev] enum discussion: can someone please summarize open issues?

Guido van Rossum guido at python.org
Mon Apr 29 06:09:42 CEST 2013

On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Functions are descriptors, so this rule already covers ordinary methods. The
> slight concern I have with making the duck typed exclusion only descriptors
> (rather than descriptors and callables) is that it means things like
> functools.partial objects will be treated as enum values rather than as
> static methods. OTOH, explicitly wrapping such callables in staticmethod
> should still work, so the simpler rule is probably better.

I think the practice of using callables (other than possibly decorated
functions) as global variables is confusing at best, even in a
non-enum class, since few people will be able to predict whether they
will get the instance passed or not. So I think the rule looking only
for descriptors is superior.

There has been a whole lot more discussion in this thread. I am now
asking everyone to stop bikeshedding, even if you think *your* point
isn't bikeshedding -- the cacophony makes it impossible to hear

There are a few more issues on which I'd like to pronounce.

1. The order in which iter(Color) should produce the items. The
argument has been made that definition order is the only order that is
not easily reconstructed, and I agree. So let's use definition order,
even if that means it can't be implemented in Python 2.

2. Whether Color(x) should be allowed, and what it should mean. Taking
the example of bool, it should return an existing enum if the argument
is either a Color or one of the values used for Color items (choosing
one somehow if there are multiple with the same value -- it doesn't
matter which one), and raise an exception if the argument is neither.

  class Color(Enum):
     red = 1
     white = 2
     blue = 3

x = Color.red
assert Color(x) is Color.red
assert Color(1) is Color.red
Color(42)  # raises

(2a. We could also allow Color('red') is Color.red, but that could be
confusing, and we can already do that with getattr(Color, 'red'), and
bool('False') doesn't return False anyway, so let's not do that.)

(2b. Let's not hypergeneralize and try to make bool and enums
completely alike. I see no advantage to adding bool.True and
bool.False, nor in making enums "final" classes, or giving a meaning
to iter(bool). Type bool is its own thing, but that doesn't mean enums
can't emulate aspects of it.)

Together with my pronouncements earlier in this thread I am hoping
that Eli and Barry will update the PEP and implementation (let's give
them a week) and everyone else will quiet down. I realize we're
deviating further from flufl.enum than our initial hope, but I think
the outcome is better.

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list