[Python-Dev] enum discussion: can someone please summarize open issues? (original) (raw)

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 anyone.

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. E.g.:

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