[Python-ideas] Enums

[Barry Warsaw]

On Jul 25, 2011, at 07:43 PM, Michael Foord wrote:

>On 25 July 2011 18:34, Barry Warsaw <barry at python.org> wrote:

>> I'm not sure it would be a good idea to do a mass mechanical substitution
>> in the stdlib, so I'm not concerned that adopting enums would require a few
>> int() calls to be added.
>>
>Well, if it isn't good enough for *us* then who is it good enough for? ;-)

I only meant that we have a tradition of not doing wholesale mechanical
conversions when new features are added to the language or modules to the
stdlib.  This wouldn't be any different. :)

>Some apis (for example those exported directly from C) can't work with
>something that isn't a real int.

That might be an important enough use case to sway me!

>>>> from flufl.enum import Enum
>>>> class Thing(Enum):
>...  a = 1
>...  b = 2
>...  c = 4
>...
>>>> Thing.a | Thing.b
>Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
>TypeError: unsupported operand type(s) for |: 'EnumValue' and 'EnumValue'

Right.  That's a consequence I think of EnumValues not being ints (and no
other support for such operations being added.

>Sure, I have no use case for ordering enums... I'm not sure I have a
>specific reason to *prevent* if that is extra work though.

Possibly so.  I think my aversion to it is seeing things like

    >>> if Colors.red < Colors.blue:

or even

    >>> if color < Colors.blue:

Most enums (at least IME) are discrete objects that don't have a natural
ordering.

-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110725/35597f40/attachment.pgp>