[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Nick Coghlan ncoghlan at gmail.com
Sun Apr 21 07:25:05 CEST 2013

On Sun, Apr 21, 2013 at 9:10 AM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Sun, 21 Apr 2013 08:34:39 +1000, Tim Delaney <timothy.c.delaney at gmail.com> wrote:
>> On 21 April 2013 04:10, Barry Warsaw <barry at python.org> wrote:
>> > On Apr 13, 2013, at 08:37 AM, Tim Delaney wrote:
>> >
>> > >Just using definition order as the stable iteration order would do the
>> > >trick - no need for any comparisons at all. Subclasses (e.g. IntEnum) can
>> > >then override it.
>> >
>> > I think this isn't possible if we want to keep backward compatibility with
>> > earlier Pythons, which I want to do.
>> Do you want it compatible with Python 2.x? In that case I don't see a way
>> to do it - getting definition order relies on __prepare__ returning an
>> ordered dict, and __prepare__ of course is only available in 3.x.
> It seems strange to limit a new Python3 feature to the Python2 feature
> set.  Just saying :)

Agreed. I think the stdlib enum library should use __prepare__ and
iterate in definition order (since 2.x compatibility isn't of any
concern), while flufl.enum can use "sorted by name" as the iteration

An "order_by_name" keyword argument to __prepare__ in the stdlib
version could then allow the user to opt in to the flufl.enum
behaviour, while still using definition order by default.

As in:

    class DefinitionOrder(enum.Enum):
        first = 1
        second = 2
        third = 3

    list(DefinitionOrder) -> [DefinitionOrder.first,
DefinitionOrder.second, DefinitionOrder.third]


    class NameOrder(enum.Enum, order_by_name=True):
        a = 1
        c = 2
        b = 3

    list(NameOrder) -> [NameOrder.a, NameOrder.b, NameOrder.c]

flufl.enum could also offer the "order_by_name" flag on 3.x, but set
it to "True" by default.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list