[Python-ideas] adopt an enum type for the standard library?

Raymond Hettinger python at rcn.com
Thu Jan 24 17:53:21 CET 2008

>> Over years of looking at tons of Python code, I've seen several variants of
>> enums.  In *every* case, they were just a toy recipe and were not be used
>> in anything other than demo code.

[Mark Summerfeld]
> Did you also see lots of examples of people creating their own set
> types?

> Until something is part of the language or library people will
> toy with their own version but probably won't commit to it. But once
> something is standardised it gets used---if it is general purpose.

This is true.  Unfortunately, it means that if you add something to
the language that shouldn't be there, it will get used also.  When
a tool is present, it suggests that the language designers have 
thought it through and are recommending it.  It then takes time
and experience to unlearn the habit (for example, it takes a while
to learn that pervasive isinstance() checks get in the way of
duck typing).  This is doubly true for features that are found
in compiled languages but of questionable value in a dynamic

IMO, the hardest thing for a Python newbie is to stop coding
like a Java programmer.

>> There are already so many reasonable ways to do this or avoid doing it,
>> that it would be silly to add an Enum factory.
> I thought that one of Python's strengths was supposed to be that in
> general there is just one best way to do things.

It's strange that you bring that up as argument for adding yet another
type of namespace.

> None of the examples you gave provides any level of const-ness.

That is not a virtue.  It is just psuedo const-ness.  It is dog slow
and not compiled as a constant.  All you're getting is something
that is harder to write to.  That doesn't make sense in a 
consenting adults environment.

Take a look through the standard library at how many times we
make an attribute read-only by using property().  It is just not
our style.

BTW, the rational module needs to undo that choice for
numerator and denominator.  It makes the code slow
for basically zero benefit.

[Jonathan Marshall]
> we find that experienced python programmers are use to the
> absence of a standard enum type but new python programmers
> are surprised by its absence

I think this is a clear indication that new programmers all wrestle
with learning to write Pythonically instead of making shallow
translations of code they would have written in statically compiled
languages. Adding something like Enum() will only reinforce those
habits and slow-down their progress towards becoming a good
python programmer.


More information about the Python-ideas mailing list