[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Guido van Rossum guido at python.org
Fri Apr 26 23:41:23 CEST 2013


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.

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

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.

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


More information about the Python-Dev mailing list