Minor change to Enum -- should it go into 3.5.2?
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
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
On 05/08/2016 03:29 PM, Guido van Rossum wrote:
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?
No, but with the change code that works in 3.5.2 could break in 3.5.1 or 3.5.0. It's a 2/3 compatibility issue with enum34 and aenum which support _order_, and Python3.4+ which does not. The work-around is to use __order__ instead (or use enum34 or aenum instead ;) . Either way, it's only similarity to a bug is I should have named it _order_ in the beginning, and put the compatibility shim into the stdlib version at the same time. -- ~Ethan~
On Sun, May 8, 2016 at 3:43 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 05/08/2016 03:29 PM, Guido van Rossum wrote:
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?
No, but with the change code that works in 3.5.2 could break in 3.5.1 or 3.5.0.
That's bad too (and it's one reason why we're generally strict about the "no new features in bugfix releases" rule.
It's a 2/3 compatibility issue with enum34 and aenum which support _order_, and Python3.4+ which does not. The work-around is to use __order__ instead (or use enum34 or aenum instead ;) .
Either way, it's only similarity to a bug is I should have named it _order_ in the beginning, and put the compatibility shim into the stdlib version at the same time.
I think it's a case of water under the bridge and learning to live with your mistakes. -- --Guido van Rossum (python.org/~guido)
On 9 May 2016 at 08:43, Ethan Furman <ethan@stoneleaf.us> wrote:
On 05/08/2016 03:29 PM, Guido van Rossum wrote:
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?
No, but with the change code that works in 3.5.2 could break in 3.5.1 or 3.5.0.
It's a 2/3 compatibility issue with enum34 and aenum which support _order_, and Python3.4+ which does not. The work-around is to use __order__ instead (or use enum34 or aenum instead ;) .
Needing to use a PyPI alternative to a stdlib module for increased cross-version consistency is a pretty common experience these days, so I think that's OK - end users can choose for themselves between the stability of the stdlib version and the reduced update latency of the PyPI version. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
I wonder if we should add something for this? --Guido (mobile) On May 8, 2016 7:18 PM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 9 May 2016 at 08:43, Ethan Furman <ethan@stoneleaf.us> wrote:
On 05/08/2016 03:29 PM, Guido van Rossum wrote:
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?
No, but with the change code that works in 3.5.2 could break in 3.5.1 or 3.5.0.
It's a 2/3 compatibility issue with enum34 and aenum which support _order_, and Python3.4+ which does not. The work-around is to use __order__ instead (or use enum34 or aenum instead ;) .
Needing to use a PyPI alternative to a stdlib module for increased cross-version consistency is a pretty common experience these days, so I think that's OK - end users can choose for themselves between the stability of the stdlib version and the reduced update latency of the PyPI version.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ 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
On 05/08/2016 07:15 PM, Nick Coghlan wrote:
On 9 May 2016 at 08:43, Ethan Furman wrote:
It's a 2/3 compatibility issue with enum34 and aenum which support _order_, and Python3.4+ which does not. The work-around is to use __order__ instead (or use enum34 or aenum instead ;) .
Needing to use a PyPI alternative to a stdlib module for increased cross-version consistency is a pretty common experience these days, so I think that's OK - end users can choose for themselves between the stability of the stdlib version and the reduced update latency of the PyPI version.
Are you saying I shouldn't bother updating the 3.6 Enum to ignore _order_? -- ~Ethan~
On 9 May 2016 at 12:39, Ethan Furman <ethan@stoneleaf.us> wrote:
On 05/08/2016 07:15 PM, Nick Coghlan wrote:
Needing to use a PyPI alternative to a stdlib module for increased cross-version consistency is a pretty common experience these days, so I think that's OK - end users can choose for themselves between the stability of the stdlib version and the reduced update latency of the PyPI version.
Are you saying I shouldn't bother updating the 3.6 Enum to ignore _order_?
I don't have an opinion on the change itself (although keeping PyPI and 3.6-to-be aligned seems reasonable), just that it's OK to suggest folks use a backport module even on earlier 3.x versions if they want the behaviour of the latest (or even the next upcoming) stdlib release, rather than the baseline behaviour of their current runtime. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
Ethan Furman -
Guido van Rossum -
Guido van Rossum -
Nick Coghlan