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" <et...@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 >
_______________________________________________ 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/archive%40mail-archive.com