(original) (raw)

On 22 April 2013 10:31, Barry Warsaw <barry@python.org> wrote:

On Apr 22, 2013, at 09:31 AM, Tim Delaney wrote:

\>I'm fine with iteration order being by sorted name by default, so long as
\>it's easily overrideable by enum subclasses or metaclasses e.g. an IntEnum
\>should probably iterate in value order.

It does. :)

I knew it \*did\*, but wasn't sure if with the current discussion it was going to continue to do so.

\>For definition order, a 3.x-only metaclass could be provided:
\>
\>class Days(enum.Enum, metaclass=enum.DefinitionOrder):
\> Monday = 1
\> Tuesday = 2
\> Wednesday = 3
\> Thursday = 4
\> Friday = 5
\> Saturday = 6
\> Sunday = 7

Yep, that's how it works. From flufl.enum:

class IntEnumMetaclass(EnumMetaclass):
\# Define an iteration over the integer values instead of the attribute
\# names.
def \_\_iter\_\_(cls):
for key in sorted(cls.\_enums):
yield getattr(cls, cls.\_enums\[key\])

Would it be worthwhile storing a sorted version of the enum keys here? Or do you think the current space vs speed tradeoff is better?

I need to grab the current flufl.enum code and see if I can easily extend it to do some more esoteric things that my enum implementation supports (\*not\* bare names, but maybe the name = ... syntax, which of course requires the definition order metaclass). I'm in the middle of a release cycle, so my time is somewhat limited right now :(

Tim Delaney