On 26 February 2013 07:32, Barry Warsaw <ba...@python.org> wrote: > One thing I've been thinking about is allowing you to override the > EnumValue > class that the metaclass uses. In that case, if you really wanted ordered > comparisons, you could override __lt__() and friends in a custom enum-value > class. I haven't quite worked out in my mind how that would look, but I > have > a bug to track the feature request: > > https://bugs.launchpad.net/flufl.enum/+bug/1132976 > > Heck, that might even allow you to implement int-derived enum values if you > really wanted them <wink>. >
You're starting to tread in an area that I investigated, did an implementation of, and then started moving away from due to a different approach (delegating to the methods in the owning Enum class when accessing EnumValue attribtues). I haven't touched my implementation for a couple of weeks now - been busy with other stuff and I got a bit fatigued with the discussion so I decided to wait until things had settled a bit. Hasn't happened yet ... ;) I'm actually in a quandry about what way I want my enums to go. I think each enum should have an ordinal based on the order it is defined, and should be ordered by that ordinal. But (whether or not it inherits from int - I'm ignoring string enums here) should __int__ and __index__ return the ordinal, or the assigned int value (if it has one)? There are arguments both ways. My current implementation doesn't have an ordinal at all (except by accident in the trivial case). That was when I decided to put it aside for a while and see where the discussion went. Tim Delaney
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
