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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
