Python will have enums in 3.4!

May 10th, 2013 at 6:06 am

After months of intensive discussion (more than a 1000 emails in dozens of threads spread over two mailing lists, and a couple of hundred additional private emails), PEP 435 has been accepted and Python will finally have an enumeration type in 3.4!

The discussion and decision process has been long and arduous, but eventually very positive. A collective brain is certainly better than any single one; the final proposal is better in a number of ways than the initial one, and the vast majority of Python core developers now feel good about it (give or take a couple of very minor issues).

I’ve been told enums have been debated on Python development lists for years. There’s at least one earlier PEP (354) that’s been discussed and rejected in 2005.

I think part of the success of the current attempt can be attributed to the advances in metaclasses that has been made in the past few releases (3.x). These advances allow very nice syntax of enum definitions that provides a lot of convenient features for free. I tried to find interesting examples of metaclasses in the standard library in 2011; Once the enum gets pushed I’ll have a much better example :-)

Related posts:

  1. Python metaclasses by example
  2. Helping improve the documentation of Python

12 Responses to “Python will have enums in 3.4!”

  1. Christoph ZwerschkeNo Gravatar Says:

    The enums also build upon other new features such as ordered dictionaries. It took some time until it was possible to have an implementation that is really satisfactory. I like it.

  2. elibenNo Gravatar Says:


    To be completely fair, OrderedDict has been available since 2.7 and its functionality was easy to implement even before that. Features like a metaclass’s __prepare__, OTOH, are much harder to fake without actually having them.

  3. ConceptJunkieNo Gravatar Says:

    This is excellent. I’m a newcomer to Python after almost 20 years of mostly C++ and I am totally in love with this language, and the lack of enums (or something close enough to them) was one of the few things I did not like. Python has quickly become my language of choice for any scripting or quick utilities I need to write. I’d love to develop something bigger in it, but my main job will still be in C++ for the foreseeable future.

  4. PetraNo Gravatar Says:

    How much of a change this is given we already have namedtuples and c like structs in standard library??

    Seems I don’t have a clue what the big deal is..

  5. elibenNo Gravatar Says:


    nametuple is a very different beast. And C-like structs? Not sure what you’re talking about.

  6. Christoph ZwerschkeNo Gravatar Says:

    @eliben: True, I didn’t want to imply that OrderedDict were so important for Enum. Just pointing out how smoothly things fit together now, and that it’s sometimes better to wait for the right time to add a feature. The slow, but steady and evolutionary development of Python is really nice to see.

  7. DaverzNo Gravatar Says:


    There are two modules in the standard library that provide C structs, the struct module and the ctypes module (ctypes.Structure). I prefer using ctypes for this.

    Of course, these are usually used for reading/writing binary data from/to a file. I wouldn’t use them when I needed something “struct-like” in an app (well, maybe Real Men do it that way). I’d usually use a class in that case.

  8. elibenNo Gravatar Says:


    Yes, I’m aware of the struct module (which has little in common with C-like structures except the name) and ctypes.Structure. But as you correctly note, these hardly designed to be actually used as convenient structures, and have even less in common with enums (which is what the original comment was referring to).

  9. Shawn FumoNo Gravatar Says:

    Any idea if this will get backported somehow so we can use it in 2.x?

  10. elibenNo Gravatar Says:

    @Shawn Fumo,

    It cannot be fully backported because some features of Python 3.x are used. But most of the functionality can be backported, although it won’t be done officially since there isn’t going to be Python version 2.8 (see

  11. SDSNo Gravatar Says:

    Hey, there was a very interesting discussion regarding enumerations and bitmasks which seems to have fizzled out without reaching a consensus. I really liked the suggestion of “random832″, has this been discussed, resolved, or implemented (atop the new enum module) anywhere else?


    Also, is this available as a package for 3.3 without waiting?

  12. elibenNo Gravatar Says:


    Bitmasked sets of constants were not deemed a good fit for the Enum design and were left out. For 3.3 and earlier Pythons, see the enum34 package on PyPi.

Leave a Reply

To post code with preserved formatting, enclose it in `backticks` (even multiple lines)