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

Ethan Furman ethan at stoneleaf.us
Thu Apr 25 23:37:29 CEST 2013

On 04/25/2013 02:25 PM, Eli Bendersky wrote:
> On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw <barry at python.org <mailto:barry at python.org>> wrote:
>> On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote:
>>> For me, the getitem syntax on a class seems odd and the call syntax is
>> Not if you think of it as a lookup operation instead of an instantiation
>> operation.  It really is the former because neither syntax creates new enum
>> item objects, it just returns an already existing one.
> I think it's important to stress what this syntax is actually going to be used for. No one (I hope) is actually going to
> write Animals(1) or Animals[1]. They will write Animals.ant - this is what enums are for in the first place! The way I
> see it, this syntax is for enabling *programmatic access* - if you pull the value from a DB and want to convert it to an
> actual enum value, etc. So do we really need to have two syntaxes for this?
> The call syntax already has other uses, and it's weird because:
> Enum(....) -> Creates new enums
> Animals(....) --> accesses values ?! This is contradictory
> Animals[...] to serve as a by-value lookup makes sense, though.

How about consistency?

If I'm converting several types of items from a database I'd like to do something like:

result = []
for field in row:
     type = get_type(field)      # returns int, bool, str, or an Enum type

What you're suggesting means complicating the logic:

result = []
for field in row:
     type = get_type(field)      # returns int, bool, str, or an Enum type
     if isinstance(type, Enum):

We just got NoneType fixed to actually return None instead of raising an error for this same type of scenario, why 
should we muddy it up again?


More information about the Python-Dev mailing list