Re: [openstack-dev] OK to Use Flufl.enum

2013-12-13 Thread Yuriy Taraday
Hello, Adam.

On Tue, Dec 10, 2013 at 6:55 PM, Adam Young ayo...@redhat.com wrote:

  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


Looks like you're doing this the wrong way. Python 3.4's enums work either
as EnumClass(value) or as EnumClass[name], not as EnumClass[value] as it
seems your test is doing and flufl is allowing it to.

-- 

Kind regards, Yuriy.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Flavio Percoco

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.



Alex


On Mon, Dec 9, 2013 at 7:37 PM, Adam Young ayo...@redhat.com wrote:

   While Python 3 has enumerated types, Python 2 does not, and the standard
   package to provide id, Flufl.enum, is not yet part of our code base.  Is
   there any strong objection to including Flufl.enum?

   http://pythonhosted.org/flufl.enum/

   It makes for some very elegant code, especially for enumerated integer
   types.

   For an example See ScopeType in

   https://review.openstack.org/#/c/55908/4/keystone/contrib/revoke/core.py

   Line 62.

   the getter/setter in RevokeEvent do not need to do any conditional logic if
   passed either an integer or a ScopeType.


   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
I disapprove of what you say, but I will defend to the death your right to say
it. -- Evelyn Beatrice Hall (summarizing Voltaire)
The people's good is the highest law. -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
@flaper87
Flavio Percoco


pgpc1OiyWfCmu.pgp
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Davanum Srinivas
Adam,

I don't see it in the global requirements [1], needs to be added there
first i think.

-- dims

[1] 
https://github.com/openstack/requirements/blob/master/global-requirements.txt

On Tue, Dec 10, 2013 at 5:24 AM, Flavio Percoco fla...@redhat.com 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.



 Alex


 On Mon, Dec 9, 2013 at 7:37 PM, Adam Young ayo...@redhat.com wrote:

While Python 3 has enumerated types, Python 2 does not, and the
 standard
package to provide id, Flufl.enum, is not yet part of our code base.
 Is
there any strong objection to including Flufl.enum?

http://pythonhosted.org/flufl.enum/

It makes for some very elegant code, especially for enumerated integer
types.

For an example See ScopeType in


 https://review.openstack.org/#/c/55908/4/keystone/contrib/revoke/core.py

Line 62.

the getter/setter in RevokeEvent do not need to do any conditional
 logic if
passed either an integer or a ScopeType.


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 --
 I disapprove of what you say, but I will defend to the death your right
 to say
 it. -- Evelyn Beatrice Hall (summarizing Voltaire)
 The people's good is the highest law. -- Cicero
 GPG Key fingerprint: 125F 5C67 DFE9 4084


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 @flaper87
 Flavio Percoco

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Davanum Srinivas :: http://davanum.wordpress.com

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Adam Young

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.







Alex


On Mon, Dec 9, 2013 at 7:37 PM, Adam Young ayo...@redhat.com wrote:

   While Python 3 has enumerated types, Python 2 does not, and the 
standard
   package to provide id, Flufl.enum, is not yet part of our code 
base.  Is

   there any strong objection to including Flufl.enum?

   http://pythonhosted.org/flufl.enum/

   It makes for some very elegant code, especially for enumerated 
integer

   types.

   For an example See ScopeType in

https://review.openstack.org/#/c/55908/4/keystone/contrib/revoke/core.py

   Line 62.

   the getter/setter in RevokeEvent do not need to do any conditional 
logic if

   passed either an integer or a ScopeType.


   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
I disapprove of what you say, but I will defend to the death your 
right to say

it. -- Evelyn Beatrice Hall (summarizing Voltaire)
The people's good is the highest law. -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Ben Nemec

On 2013-12-09 21:37, Adam Young wrote:

While Python 3 has enumerated types, Python 2 does not, and the
standard package to provide id, Flufl.enum, is not yet part of our
code base.  Is there any strong objection to including Flufl.enum?

http://pythonhosted.org/flufl.enum/

It makes for some very elegant code, especially for enumerated integer 
types.


For an example See ScopeType in

https://review.openstack.org/#/c/55908/4/keystone/contrib/revoke/core.py

Line 62.

the getter/setter in RevokeEvent do not need to do any conditional
logic if passed either an integer or a ScopeType.


flufl.enum requires Python 2.7 or newer, and is compatible with Python 
3.2 and later.


I think we're still supporting 2.6 at the moment, aren't we?  This would 
be a problem until we drop that.


-Ben

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Jay Pipes

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


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Alex Gaynor
 from flufl.enum import IntEnum
 class A(IntEnum):
...   a = 3
...
 A.a
EnumValue: A.a [value=3]


Alex


On Tue, Dec 10, 2013 at 8:23 AM, Jay Pipes jaypi...@gmail.com wrote:

 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




-- 
I disapprove of what you say, but I will defend to the death your right to
say it. -- Evelyn Beatrice Hall (summarizing Voltaire)
The people's good is the highest law. -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Chmouel Boudjnah
On Tue, Dec 10, 2013 at 5:23 PM, Jay Pipes jaypi...@gmail.com wrote:

 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.



this is the kind of things you can do with the new Enums :

http://blog.dbrgn.ch/2013/5/10/python-enum-type/

I personally don't find them very useful either but they may have some use
cases.

Chmouel.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Jay Pipes

On 12/10/2013 11:26 AM, Alex Gaynor wrote:

  from flufl.enum import IntEnum
  class A(IntEnum):
...   a = 3
...
  A.a
EnumValue: A.a [value=3]


If the __repr__ is *really* the only value of IntEnum, I'm less than 
impressed.


-jay


On Tue, Dec 10, 2013 at 8:23 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:

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
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
I disapprove of what you say, but I will defend to the death your right
to say it. -- Evelyn Beatrice Hall (summarizing Voltaire)
The people's good is the highest law. -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-10 Thread Adam Young

On 12/10/2013 11:43 AM, Jay Pipes wrote:

On 12/10/2013 11:26 AM, Alex Gaynor wrote:

  from flufl.enum import IntEnum
  class A(IntEnum):
...   a = 3
...
  A.a
EnumValue: A.a [value=3]


If the __repr__ is *really* the only value of IntEnum, I'm less than 
impressed.


-jay


On Tue, Dec 10, 2013 at 8:23 AM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:

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


Jay,  It is the other way around:  How do you go from an integer to one 
of the pre-defined values?


I want 1, 2, 3, and 4 to be valid, but not 0 or 6, and each to map to 
both a Symbolic and a text based representation.


In the database store 1, 2, 3, 4

From the outside world I want to parse user, project, domain  etc.





from text parse user, project, domain, trust

Instead of having to to an explicit translation.  Doing it once is no 
big deal.  It is the need to do it for every enumerated field in 
Keystone that made me look into how to do a standardized enumeration.












_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
I disapprove of what you say, but I will defend to the death your right
to say it. -- Evelyn Beatrice Hall (summarizing Voltaire)
The people's good is the highest law. -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] OK to Use Flufl.enum

2013-12-09 Thread Alex Gaynor
Would it make sense to use the `enum34` package, which is a backport of teh
enum package from py3k?

Alex


On Mon, Dec 9, 2013 at 7:37 PM, Adam Young ayo...@redhat.com wrote:

 While Python 3 has enumerated types, Python 2 does not, and the standard
 package to provide id, Flufl.enum, is not yet part of our code base.  Is
 there any strong objection to including Flufl.enum?

 http://pythonhosted.org/flufl.enum/

 It makes for some very elegant code, especially for enumerated integer
 types.

 For an example See ScopeType in

 https://review.openstack.org/#/c/55908/4/keystone/contrib/revoke/core.py

 Line 62.

 the getter/setter in RevokeEvent do not need to do any conditional logic
 if passed either an integer or a ScopeType.


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
I disapprove of what you say, but I will defend to the death your right to
say it. -- Evelyn Beatrice Hall (summarizing Voltaire)
The people's good is the highest law. -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev