[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

[Tim Delaney]

On 26 February 2013 07:32, Barry Warsaw <barry at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130226/efc22dc1/attachment-0001.html>