(original) (raw)

If enum were provisional it would be okay, but since it isn't, I think this change can't go into 3.5.2\. Think if this: could any code that works in 3.5.1 be broken by the change?

--Guido (mobile)

On May 8, 2016 1:11 PM, "Ethan Furman" <ethan@stoneleaf.us> wrote:

Currently, the Enum creation process ignores \_\_dunder\_\_ attributes, and blocks all \_sunder\_ attributes.

Because of this, the enum34 backport used \_\_order\_\_ instead of \_order\_ to provide a mechanism for ordering the enum members (which I never really liked).

However, I've been working on my aenum \[1\] package, which uses several other \_sunder\_ attributes (for python2 compatibility) so I enabled \_order\_ instead and promote that spelling in the docs.

Unlike the other \_sunder\_ attributes, \_order\_ has no meaningful affect in Python 3 so I'd like to change the stdlib Enum to allow it (and either ignore completely, or check it is the same as the definition order).

My question is: Should I put this change in 3.5.2?

\- Yes means 3.5.2+ will work with \_order\_, 3.4, 3.5.0, and 3.5.1
will not;

\- No means 3.4 and all of 3.5 will not.

\--
\~Ethan\~

\[1\] https://pypi.python.org/pypi/aenum
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org