Repository navigation
Enum: mixin classes don't mix well with already mixed Enums #73763
Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/ethanfurman'
closed_at = <Date 2019-07-16.03:27:52.424>
created_at = <Date 2017-02-16.02:09:44.122>
labels = ['3.8', 'type-bug', 'library']
title = "Enum: mixin classes don't mix well with already mixed Enums"
updated_at = <Date 2019-07-16.03:27:52.423>
user = 'https://github.com/ethanfurman'bugs.python.org fields:
activity = <Date 2019-07-16.03:27:52.423>
actor = 'ethan.furman'
assignee = 'ethan.furman'
closed = True
closed_date = <Date 2019-07-16.03:27:52.424>
closer = 'ethan.furman'
components = ['Library (Lib)']
creation = <Date 2017-02-16.02:09:44.122>
creator = 'ethan.furman'
dependencies = []
files = []
hgrepos = []
issue_num = 29577
keywords = ['patch']
message_count = 6.0
messages = ['287910', '287914', '287931', '287934', '326065', '326077']
nosy_count = 4.0
nosy_names = ['barry', 'eli.bendersky', 'ethan.furman', 'zero.piraeus']
pr_nums = ['9328', '9486']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue29577'
versions = ['Python 3.8']
Activity
ethanfurman commentedon Feb 16, 2017
Consider:
--------
The Color class works fine, but the IntColor fails. This is due to the way the base data type and __new__ method is discovered. If we switch the order of the bases
it works, but having to put the mixin class last is both bizarre and unworkable when the mixin should be overriding behavior.
ethanfurman commentedon Feb 16, 2017
To get the above code snippet to fail properly:
ethanfurman commentedon Feb 16, 2017
While only IntColor fails with an error, Color also fails as it is not a Flag type Enum:
>>> list(Color) [<Color.RED: 1>, <Color.BLUE: 2>, <Color.GREEN: 3>]It should have values of 1, 2, 4.
ethanfurman commentedon Feb 16, 2017
Possibilities:
only allow one base Enum class
(fails with All and IntFlag)
only allow base Enum classes that are compatible
(so not an Enum and a Flag)
(would require multiple base classes for the same behavior: DocEnum,
DocFlag, etc.)
only allow one mixin
(before/after that one mixin the inheritance is linear)
(same issue as above)
only allow one non-Enum mixin, critical Enum is last one in the bases,
previous Enums in bases are mixins
(all sunder/dunder methods come from critical Enum, all normal methods
and attributes are in normal base order)
be smarter about determining/saving the correct __new__ and base data type
The last one needs to happen, and some form of the next-to-last one (hopefully allowing for more than one non-Enum mixin).
ethanfurman commentedon Sep 22, 2018
New changeset 5bdab64 by Ethan Furman in branch 'master':
bpo-29577: Enum: mixin classes don't mix well with already mixed Enums (GH-9328)
5bdab64
ethanfurman commentedon Sep 22, 2018
New changeset 0c076ca by Ethan Furman in branch '3.7':
[3.7] bpo-29577: Enum: mixin classes don't mix well with already mixed Enums (GH-9328) (GH-9486)
0c076ca