[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)

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 TOOWTDI. 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 result.append(type(field))

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): result.append(type[field]) else: result.append(type(field))

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?

-- Ethan

More information about the Python-Dev mailing list