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

Ethan Furman ethan at stoneleaf.us
Fri Apr 26 01:03:47 CEST 2013

On 04/25/2013 03:46 PM, R. David Murray wrote:
> On Thu, 25 Apr 2013 14:37:29 -0700, Ethan Furman <ethan at stoneleaf.us> wrote:
>> 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?
> I haven't cared much about this particular bikeshed, but I find this a
> somewhat compelling argument.  I'm working on a system that depends on
> exactly this standard behavior of (most?) built in types in Python: if
> you pass an instance or something that can be converted to an instance
> to the type constructor, you get back an instance.  If Enums break that
> paradigm(*), someone would have to write a custom class that provided
> that behavior in order to use Enums with my system.  I wouldn't say that
> was a show stopper, especially since my system may never go anywhere :),
> but it certainly is an exemplar of the issue Eli is talking about.

Um, did you mean "of the issue Ethan is talking about"?  'Cause Eli is against it.

> (*) Hmm.  NoneType(None) is still an error.

Hmm, so it is.  When I pushed for the change just having NoneType() work was sufficient.


More information about the Python-Dev mailing list