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

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

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