[Python-Dev] enum discussion: can someone please summarize open issues?

Ethan Furman ethan at stoneleaf.us
Mon Apr 29 04:46:59 CEST 2013

On 04/28/2013 06:52 PM, Steven D'Aprano wrote:
> On 29/04/13 10:29, Ethan Furman wrote:
>> On 04/28/2013 04:37 PM, Steven D'Aprano wrote:
>>>> On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>>>>    - should an enum item be selectable via __call__ instead of __getitem__
>>>>> (i.e. Season(3) is AUTUMN)
>>> Does anyone know why this is even an issue? Is this pure bike-shedding over the API, or are there
>>> technical reasons for choosing one over the other?
>> This is an issue because currently every other type* in Python creates (or selects ;) its instances via the call syntax:
>>    - bool(1)    # True
>>    - int('11')  # 11
>>    - str(var)   # whatever var had in it, now as a str
> I think that's a red herring, because you're comparing the use of the object constructor with look-up by name.

int, float, and bool all have object constructors that take the given string and return a matching instance; int /may/ 
return a pre-existing instance, bool /will/ return a pre-existing instance.

As I've stated before, 'bool's are the closest existing data type to enums, in that bools use the object constructor to 
convert the incoming parameter to an existing bool instance, of which there will only ever be two.

bool(9) is bool('maybe') is bool(True) is True

and similarly, Enum behavior /should be/ (in my opinion ;)

Season.AUTUMN is Season('AUTUMN') is Season(3)

Like it or not, when you write `class Season(Enum)` a new *type* is created called Season, and Season(x) should either 
return a Season instance that matches x or raise.  Having a match and raising anyway just doesn't seem to me to be the 
Python Way.

>> But one of the latest changes to flufl.enum was to take out the call syntax, and have only getitem syntax
>>    - Season('AUTUMN')  # raises an exception
>>    - Season['AUTUMN']  # Season.AUTUMN
> I'm not sure whether flufl.enums support creating additional instances after the event, but if it did, I would expect
> that I could say Season('WET') to get a new instance. I am indifferent to whether or not Season('AUTUMN') should return
> the existing AUTUMN enum value.

Adding more enumerators after the fact should not be supported; there is subclassing for that. Not worth actively 
preventing, but not encouraged.


More information about the Python-Dev mailing list