On 25/07/2011 07:32, Chris Rebert wrote:
On Sun, Jul 24, 2011 at 11:04 PM, Stefan Behnel<stefan_ml@behnel.de> wrote:
Ben Finney, 25.07.2011 04:09:
Guido van Rossum writes:
For enums, I think we should just pick a solution. I'm in favor of Barry Warsaw's version, flufl.enum.
As the maintainer of the PyPI ‘enum’ package, I also support the FLUFL's ‘flufl.enum’ to be the One Obvious Way.
Never used enums in Python, and likely won't do so anywhere in the near future, but I just read through the usage page at
http://packages.python.org/flufl.enum/docs/using.html
and *if* such a library gets added to the stdlib, then this is the way it should work. The examples totally make sense to me.
My only nitpicks would be: - Why violate TOOWTDI by having both SomeEnum(...) and SomeEnum[...] that do the same thing? - Why is it .enumname and not simply .name? .enumname could also be confused as getting the name of the overarching enum rather than the name of the particular enum value.
My nitpick would be that the underlying integer values should start at 0, not 1.