[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)

Eli Bendersky eliben at gmail.com
Sat Apr 27 01:01:08 CEST 2013

On Fri, Apr 26, 2013 at 2:41 PM, Guido van Rossum <guido at python.org> wrote:

On Fri, Apr 26, 2013 at 11:17 AM, Eli Bendersky <eliben at gmail.com> wrote: > On Fri, Apr 26, 2013 at 10:36 AM, Guido van Rossum <guido at python.org> wrote: >> > On 4/25/2013 9:19 PM, Guido van Rossum wrote: >> I think you've lost track of the Zen of Python. > > I feel that this thread has lost track of it long ago.

Perhaps. The thread certainly has lost focus -- there are separate subthreads about the ordering of items when iterating over the enum class and about the unification of the Enum and EnumValue classes, and perhaps others.

I agree, and thanks for the thoughtful reply to my half-rant ;-) More comments below.

> Some time back in the > Enum discussions (some 350 messages ago or so), there was a proposal to have > this: > > class Color(Enum): > RED, BLUE, GREEN > > By doing some crazy-cool shenanigans. Although the syntax is great, it was > rejected on the basis of being too magic. FWIW, I didn't think the syntax was great. "Great" syntax would have been something like enum Color: RED, BLUE, GREEN but introducing a new keyword isn't justifiable. > The recent proposals of folding Enum and EnumValue into one, having class > members be instances of the class they're members of while supporting a > bunch of other Enum requirements also go off the rails in terms of > complexity and magic. Yet the goal of the proposal is conceptual simplification: one class instead of two. But users are not exposed to two classes. And for us, implementors, keeping things separate is IMHO simplification. There's a conceptual difference between a value of an enumeration and a collection of such values. This difference helps, I think, make IntEnum possible relatively easily - we can actually have an enumerated value that is-a integer and can be used instead of integers in legacy code. This requirement will heap additional complexity on the alternative where the enum and enum value are unified into the same class.

Having class members that are also class instances is a non-issue.

The complexity of the proposal is an implementation issue: we'd like to be able to define methods for the enum values, and the simplest way (for the user) to define methods for the enum values would be to allow def statements, possibly decorated, in the class. But now the implementation has to draw a somewhat murky line between which definitions in the class should be interpreted as enum value definitions, and which should be interpreted as method definitions. If we had access to the syntax used for the definition, this would be simple: assignments define items, def statements define methods. But at run time we only see the final object resulting from the definition, which may not even be callable in the case of certain decorators. I am still optimistic that we can come up with a rule that works well enough in practice (and the Zen rule to which I was referring was, of course, "practicality beats purity"). > In contrast, personally I feel the current proposal in PEP 435 has an appeal > from the POV of simplicity. It really is a very nice separation of concerns > between enum values and Enum as a container of such values. It even allows > significant customization (IntEnum, etc) which is pretty simple to grok. It > would be a shame to lose these for the sake of making Python a bit more like > Java. But it's not so much the "like Java" that matters to me. It's the realization that for the user who wants to define an enum type with some extra functionality, having a single class and putting the methods and the items in the same class is the simplest way to do it. The Java reference is just to point out that we're not exactly breaking new ground here.

My reference to Java was w.r.t. the static-typing-minded requirement that isinstance(Color.red, Color) == True. I don't think that 99% of use-cases will care about the type of Color.red, and those that do for obscure reasons can accept an obscure class (EnumValue-something) as long as they have something distinct to dispatch upon.

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130426/d1854409/attachment-0001.html>

More information about the Python-Dev mailing list