| msg288029 - (view) |
Author: Marc Guetg (magu) |
Date: 2017-02-17 17:59 |
|
|
|
|
|
|
|
|
| At the moment it is only possible to combine flags that already exist: from enum import * class Foo(Flag): A = auto() # 1 B = auto() # 2 AB = A | B # 3 (1 |
2) AC = auto() |
A # Fails, but should be 5 (1 |
4) ABD = auto() |
A |
B # Just taking it one step further to make a point, 11 (1 |
2 |
8) It would be nice to have this for cases when C only makes sense in combination with A but not on its own. A solution to achieve this one would need to change two things in ~/cpython/Lib/enum.py First extend class auto by: class auto: """ Instances are replaced with an appropriate value in Enum class suites. """ value = _auto_null or_value = 0 def __or__(self, other): """ Postpone the real or operation until value creation in _EnumDict """ self.or_value |
= other return self And second change one line in _EnumDict: value = value.value changes to: value = value.value |
value.or_value Some simple tests show the expected results: print(repr(Foo.A)) # A - 1 print(repr(Foo.B)) # B - 2 print(repr(Foo.AB)) # AB - 3 print(repr(Foo.AC)) # AC - 5 print(repr(Foo.A |
Foo.AC)) # AC - 5 print(repr(Foo.A & Foo.AC)) # A - 1 print(repr(Foo.ABD)) # ABD - 11 Would it make sense to enhance python enums with that functionality? |
| msg288145 - (view) |
Author: Julien Palard (mdk) *  |
Date: 2017-02-19 16:48 |
|
|
|
|
|
|
|
|
| Your implementation looks right, but I don't see the point of defining combinations AB, AC, ABD in the Foo enum. Foo may only define A, B, C, D and outside of Foo anyone can build any needed combinations. This way it looks clear in the Foo declaration (4 lines, 4 auto()). Did I missed a usefull usage of declaring combination inside the enum? |
|
|
|
|
|
|
|
|
|
|
| msg288149 - (view) |
Author: Marc Guetg (magu) |
Date: 2017-02-19 17:51 |
|
|
|
|
|
|
|
|
| One made-up use-case would be: class LogLevel(Flags): start = auto() log1 = start | auto() log2 = start |
auto() def fun(flags, *args): if start in flags: # open log file if log1 in flags: # Log important thing 1 if log2 in flags: # Log important thing 2 if start in flags: # close log file Alternatively the same could be achieved using the existing capabilities with: class LogLevel(Flags): start = auto() _log1 = auto() log1 = start |
_log1 _log2 = auto() log2 = start |
_log2 Which is less clear imho and could potentially a problem if somebody uses LogLevel._log2 Another alternative would be that within the function we would check for all cases. eg: if (start in flags) or (log1 in flags) or (log2 in flags): Which leads to less clear code and makes the code less maintainable when log3 gets introduced. In the existing case we need to remember to change the if clause both when opening and closing the file. After the proposed change we only need to change the enum. I'm sure there are more use-cases for it. The one I'm using it for is a bit more convoluted that's why I'm not presenting it here. |
|
|
|
|
|
|
|
| msg288150 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2017-02-19 17:57 |
|
|
|
|
|
|
|
|
| Just make C and D protected or private. class Foo(Flag): A = auto() B = auto() AB = A | B _C = auto() __D = auto() AC = A |
_C ABD = A |
B |
__D |
|
|
|
|
|
|
|
| msg288395 - (view) |
Author: Ethan Furman (ethan.furman) * |
Date: 2017-02-23 01:16 |
|
|
|
|
|
|
|
|
| @Julian: Giving flag combinations their own name can be useful. For example, instead of seeing Color.GREEN|RED one can see Color.YELLOW . @Marc: I'm not convinced this is a needed change as it doesn't seem to be a common method, nor one that cannot be easily implemented independently (perhaps as a recipe in the docs). Are you aware of other enumerations that take this approach? |
|
|
|
|
|
|
|
|
|
|
| msg288396 - (view) |
Author: Ethan Furman (ethan.furman) * |
Date: 2017-02-23 01:20 |
|
|
|
|
|
|
|
|
| I also think using leading underscores is a better way to signal that a particular value is "weird". |
|
|
|
|
|
|
|
|
|
|
| msg288743 - (view) |
Author: Ethan Furman (ethan.furman) * |
Date: 2017-03-01 08:36 |
|
|
|
|
|
|
|
|
| aenum 2.0 [1] has been released. Because it also covers Python 2.7 I had to enhance its auto() to cover |, &, ^, and ~ so that Enum classes could be properly created. At this moment your choices are to use odd naming or aenum (with its enhanced auto). [1] https://pypi.python.org/pypi/aenum |
|
|
|
|
|
|
|
|
|
|
| msg288774 - (view) |
Author: Marc Guetg (magu) |
Date: 2017-03-01 19:05 |
|
|
|
|
|
|
|
|
| @ethan, didn't know about aenum, thanks for showing it to me. However it doesn't seem to support the behavior I'm after (or I'm doing something wrong) import aenum try: class Foo(aenum.Flag): a = aenum.auto() b = a | aenum.auto() except Exception as err: print(err) try: class Bar(aenum.Flag): a = aenum.auto() b = aenum.auto() |
a except Exception as err: print(err) results in unsupported operand type(s) for |
: 'int' and 'auto' exceptions must derive from BaseException where the latter might be a bug in the implementation. I do realize that I'm stuck with this for the moment. My motivation with opening this thread was that I was wondering if such a feature would be worthwhile for the community. In case there is interest in this feature I would try to run the unit test and follow all the steps to try to push it through. However I save myself the work in case the community decides that the implementation is not worth it. Which would also be fine with me, as I monkey patched it for my code - so no problem on my end. |
|
|
|
|
|
|
|
|
| msg288775 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2017-03-01 19:30 |
|
|
|
|
|
|
|
|
| I don't think it is worthwhile. Using underscored names looks pretty pythonic to me. |
|
|
|
|
|
|
|
|
|
|
| msg288779 - (view) |
Author: Ethan Furman (ethan.furman) * |
Date: 2017-03-02 00:06 |
|
|
|
|
|
|
|
|
| Serhiy, agreed. Closing. Marc, thanks, I see I missed supporting non-auto() combinations. Feel free to open an issue for that at: https://bitbucket.org/stoneleaf/aenum Either way I'll get that fixed. |
|
|
|
|
|
|
|
|
|
|