[Python-Dev] Best practices for Enum

Raymond Hettinger raymond.hettinger at gmail.com
Mon May 13 01:49:44 CEST 2013

After the long design effort for the enum module,
I'm sure there will be a forthcoming effort to apply
them pervasively throughout the standard library.

I would like to ask for a little restraint and for there to 
be individual cost/benefit evaluations for each case.

On the plus-side, the new integer-enums have a better
repr than plain integers.

For internal constants such as those in idlelib and regex,
the user won't see any benefit at all.  But there will be
a cost in terms of code churn, risk of introducing errors
in stable code, modestly slowing-down the code, making
it more difficult to apply bug fixes across multiple versions
of Python, and increased code verbosity (i.e. changing
"if direction=LEFT: ..."  to "if direction is Direction.LEFT: ...")

For external constants, some thought needs to be given to:
* is the current API working just fine (i.e. decimal's ROUND_DOWN)
* will enums break doctests or any existing user code
* will it complicate users converting from Python 2
* do users now have to learn an additional concept 
* does it complicate the module in any way

I'm hoping that enums get used only in cases where they
clearly improve the public API (i.e. cases such as sockets
that have a large number of integer constants) rather
than having a frenzy of every constant, everywhere getting
turned into an enum.

I would like to see enums used as tool for managing complexity,
rather than becoming a cause of added complexity by being used 
for every problem, the tall and small, even where it is not needed at all.

my-two-cents-ly yours,


More information about the Python-Dev mailing list