Open Stack

On 12/10/2013 09:55 AM, Adam Young wrote:
> On 12/10/2013 05:24 AM, Flavio Percoco wrote:
>> On 09/12/13 19:45 -0800, Alex Gaynor wrote:
>>> Would it make sense to use the `enum34` package, which is a backport
>>> of teh
>>> enum package from py3k?
>>
>> +1
>>
>> This is what we were using in Marconi.
> So... they seem to be doing something different from Flufl, as IntEnums
> are not working the same way.  I wonder if it is just update lag, and
> Flufl is the Upstream for the changes.
>
> With only a change to the import and requirements, it builds and runs,
> but raises:
>
> Traceback (most recent call last):
>    File "keystone/tests/test_revoke.py", line 65, in test_list_is_sorted
>      valid_until=valid_until))
>    File "keystone/contrib/revoke/core.py", line 74, in __init__
>      setattr(self, k, v)
>    File "keystone/contrib/revoke/core.py", line 82, in scope_type
>      self._scope_type = ScopeType[value]
>    File
> "/opt/stack/keystone/.venv/lib/python2.7/site-packages/enum/__init__.py", line
> 352, in __getitem__
>      return cls._member_map_[name]
> KeyError: 1
>
> This seems to say that you cannot access an IntEnum as an integer, which
> just seems broken.

What precisely is the benefit of an IntEnum? From the example in the 
flufl.enum docs:

 >>> from flufl.enum import IntEnum
 >>> class Animals(IntEnum):
...     ant = 1
...     bee = 2
...     cat = 3

 >>> int(Animals.bee)
2

Wow. That is so amazing. Thank goodness there is a library for that.

Oh wait... I can do exactly the same thing without flufl.enum or any 
other library:

 >>> class Animals:
...     ant = 1
...     bee = 2
...     cat = 3
...
 >>> int(Animals.bee)
2

The IntEnum is my new definition of the most worthless class ever 
invented in the Python ecosystem -- taking the place of zope.interface 
on my personal wall of worthlessness.

Best,
-jay