On Jul 28, 2011, at 10:30 AM, Nick Coghlan wrote:
I did see that, but I don't see a straighforward way to do it without locking the enum implementation into being *specifically* for integers.
Which is fine by me, FWIW.
1. I find the "enum" concept too limiting. NamedValue (as a mixin class) is a better building block since it separates the naming aspect from the "group of values" aspect implied by enum.
I think that's all fine, but it's getting far from *my* simple concept of enumerated values. Go for it though. :)
How is something that does *less* more complicated?
Again, looking at how I've used them extensively over the last several years, I would much rather write class Colors(Enum): red = 1 green = 2 blue = 3 than red = NamedValue('red', 1) green = NamedValue('green', 2) blue = NamedValue('blue', 3) To me, the duplication is jarring and error prone.
But the *necessity* of grouping creates a lot of boilerplate and prevents TOOWTDI.
I have no problem if folks want to add named values to the stdlib. I use namedtuple on occasion, and I wouldn't mind having named values in my arsenal, but I'm fairly certain I wouldn't use named values in the places I use Enum currently. The grouping does provide benefits such as disallowing duplicates, providing for an inheritance mechanism, and making them easier to pickle and store in (and load from) a database. I didn't original think of using enums as a replacement for module level constants, so I think we're just talking about different use cases. -Barry