On Jul 28, 2011, at 08:24 AM, Nick Coghlan wrote:
For compatibility reasons, though, I believe it is worth following the precedent set by bool: if integer constants are to be replaced by named values, the replacement needs to support everything the previous value did. The easiest way to achieve that is by inheriting directly from the previous value's type.
I mentioned in a separate follow up that I'd be open to that, if someone wants to submit a patch.
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. :)
But the grouping behaviour? I really don't see a lot of value in that - just boilerplate. We don't write bool.True and bool.False, we write True and False.
That's only because True and False are bound in a particular module namespace. There's no reason why specific EnumValues couldn't also be similarly bound. -Barry