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

Barry Warsaw barry at python.org
Sat Apr 20 21:42:59 CEST 2013

On Apr 13, 2013, at 12:51 PM, Steven D'Aprano wrote:

>I think that's too strong a restriction. I would expect to be able to do this:
>class Insect(Enum):
>     wsap = 1  # Oops, needed for backward compatibility, do not remove.
>     wasp = 1  # Preferred. Use this in new code.
>     bee = 2
>     ant = 3
>Or at the very least:
>class Insect(Enum):
>     wasp = wsap = 1
>     bee = 2
>     ant = 3
>What's the justification for this restriction? I have looked in the PEP, and
>didn't see one.

If you allowed this, there would be no way to look up an enumeration item by
value.  This is necessary for e.g. storing the value in a database.  If you
know that the "insect" column is an INTEGER that represents an enumeration
item of Insect, then you can just store the int value in the column.  To
reconstitute the actual enumeration item when you read the column back from
the database, you need to be able to look up the item by value.

Currently, you do this:

    >>> my_insect = Insect[database_value]

but if the values are not unique, you have no way to reliably do it.  I don't
much like APIs which return sequences (either always or "on demand") or rely
on definition order or some other arbitrary discrimination because I don't
think any of those are practical in the real world.

I also recall that duplication was a specific anti-feature in the previous
python-ideas discussion.  It was thought that this would allow for typos in
the set of enumeration items to creep in.

I don't see how you can reconcile these issues to allow for duplicate values.


More information about the Python-Dev mailing list