[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
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.
first = 1
second = 2
third = 3
list(DefinitionOrder) -> [DefinitionOrder.first,
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