[issue38250] enum.Flag should be more set-like

Miro Hrončok added the comment: I've reported https://bugs.python.org/issue44242 because I believe there is a regression in this change. -- nosy: +hroncok ___ Python tracker

[issue38250] enum.Flag should be more set-like

Change by STINNER Victor : -- nosy: -vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue38250] enum.Flag should be more set-like

Change by Shantanu : -- nosy: +hauntsaninja nosy_count: 6.0 -> 7.0 pull_requests: +24506 pull_request: https://github.com/python/cpython/pull/25820 ___ Python tracker ___

[issue38250] enum.Flag should be more set-like

STINNER Victor added the comment: PPC64LE Fedora Rawhide Clang Installed 3.x is back to green, thanks for the fix ;-) https://buildbot.python.org/all/#/builders/312/builds/600 -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue38250] enum.Flag should be more set-like

Ethan Furman added the comment: New changeset 01faf4542a8652adfbd3b3f897ba718e8ce43f5e by Ethan Furman in branch 'master': bpo-38250: [Enum] only include .rst test if file available (GH-24342) https://github.com/python/cpython/commit/01faf4542a8652adfbd3b3f897ba718e8ce43f5e --

[issue38250] enum.Flag should be more set-like

Change by Ethan Furman : -- pull_requests: +23161 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/24342 ___ Python tracker ___

[issue38250] enum.Flag should be more set-like

STINNER Victor added the comment: test_enum fails when Python is installed: PPC64LE Fedora Rawhide Clang Installed 3.x: https://buildbot.python.org/all/#builders/312/builds/597 0:01:37 load avg: 8.99 [232/426/1] test_enum failed -- running: test_tokenize (1 min 37 sec), test_unparse (31.7

[issue38250] enum.Flag should be more set-like

Ethan Furman added the comment: Thank you to everyone involved. :-) To answer the first three points that started this issue: 1. iteration -> each single-bit flag in the entire flag, or a combinations of flags, is returned one at a time -- not the empty set, not other multi-bit values

[issue38250] enum.Flag should be more set-like

Ethan Furman added the comment: New changeset 7aaeb2a3d682ecba125c33511e4b4796021d2f82 by Ethan Furman in branch 'master': bpo-38250: [Enum] single-bit flags are canonical (GH-24215) https://github.com/python/cpython/commit/7aaeb2a3d682ecba125c33511e4b4796021d2f82 --

[issue38250] enum.Flag should be more set-like

Ethan Furman added the comment: The code sample: class Color(IntFlag): BLACK = 0 RED = 1 GREEN = 2 BLUE = 4 PURPLE = RED | BLUE WHITE = RED | GREEN | BLUE Here's the summary of the changes: - single-bit flags are canonical - multi-bit and

[issue38250] enum.Flag should be more set-like

Change by Ethan Furman : -- pull_requests: +23042 pull_request: https://github.com/python/cpython/pull/24215 ___ Python tracker ___

[issue38250] enum.Flag should be more set-like

Change by John Belmonte : -- nosy: +jbelmonte nosy_count: 4.0 -> 5.0 pull_requests: +21698 pull_request: https://github.com/python/cpython/pull/22734 ___ Python tracker ___

[issue38250] enum.Flag should be more set-like

Vedran Čačić added the comment: Flag values are _not_ a set of enabled bits. At least, it is a weird kind of set where a is the same as {a}. That's why I mentioned mereology... there is no reasonable "membership", just "inclusion". I understand that str is not a perfect analogy, but sets are

[issue38250] enum.Flag should be more set-like

John Belmonte added the comment: I agree that a bit and one-bit flag are the same. > only 'x' was in 'xyz', not 'xy I don't understand the comparison, because str 'a in b' tests if 'a' is a subsequence of 'b'. It is not a subset operation ('xz' in 'xyz' is false). I can understand the

[issue38250] enum.Flag should be more set-like

Vedran Čačić added the comment: Again, I disagree. `str` used to work like this in Py2.0 (or somewhere around then), only 'x' was in 'xyz', not 'xy'. Then Guido came to his senses. :-) This is not set theory, this is mereology. You don't differentiate between a digit and a one-digit number,

[issue38250] enum.Flag should be more set-like

John Belmonte added the comment: It's completely undocumented, but today I noticed that Flag.__contains__() is actually a subset operation. def __contains__(self, other): ... return other._value_ & self._value_ == other._value_ It's an unfortunate departure from the

[issue38250] enum.Flag should be more set-like

John Belmonte added the comment: I think https://github.com/python/cpython/pull/1 should be reverted (considering the design issue, performance issue, and bugs), and lets have a proper design and review. While just reading the code, I found an existing bug in Flag. And the new

[issue38250] enum.Flag should be more set-like

Vedran Čačić added the comment: Of course, if it returns True only on _some_ bits combinations it doesn't make sense. I thought every element of a Boolean span would be _in_ the Foo. But about "zero bit", I still think it's perfectly analogous to '' in 'abc'. --

[issue38250] enum.Flag should be more set-like

John Belmonte added the comment: > Just a comment, (1) is analogous to str. iter('abc') gives only 'a', 'b' and > 'c', while contains accepts '', 'ab', 'bc', and 'abc' too. At least in my > mind, it's a pretty strong analogy. I don't agree. The "zero" bit does not exist, so having

[issue38250] enum.Flag should be more set-like

Vedran Čačić added the comment: Just a comment, (1) is analogous to str. iter('abc') gives only 'a', 'b' and 'c', while contains accepts '', 'ab', 'bc', and 'abc' too. At least in my mind, it's a pretty strong analogy. -- ___ Python tracker

[issue38250] enum.Flag should be more set-like

John Belmonte added the comment: Part of this issue (#1) was intended to be addressed by https://github.com/python/cpython/pull/1 which added an `__iter__` implementation to Flag and IntFlag. (The PR did not reference this issue, and was already merged last month.) However that PR

[issue38250] enum.Flag should be more set-like

Manjusaka added the comment: 1. not sure I gett the Point 2. not sure 3. absolutely yes -- nosy: +Manjusaka ___ Python tracker ___

[issue38250] enum.Flag should be more set-like

Vedran Čačić added the comment: 1. +0 _if_ the implementation is easy to explain. If backward compatibility is an issue, we can always add a property: for flag in flags.set: (though set might imply unorderedness:) 2. -1. Guido said long ago that all lens should be O(1). (Of course, if you do

[issue38250] enum.Flag should be more set-like

Change by Ethan Furman : -- assignee: -> ethan.furman nosy: +ethan.furman ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue38250] enum.Flag should be more set-like

New submission from John Belmonte : I would like Flag class instances to have more set-like abilities: 1. iteration, to walk through each set bit of the value 2. len corresponding to #1 3. subset operator I may be told "implement it yourself as instance methods", or that #3 has an idiom