[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: The values used in Flags are an implementation detail. The expected, and supported, use is naming the flags: class Color(Flags): Red, Green, Blue even custom names can be set using this method: >>> class Color(enum.Flags): ... red, green, blue ...

[issue23591] Add Flags and IntFlags

Vedran Čačić added the comment: I suppose you'll also forbid adding new members to Flags, just like Enum does, right? (https://docs.python.org/3/library/enum.html#restricted-subclassing-of-enumerations) Otherwise cropping -1 at a fixed number of bits might be very counterintuitive. But

[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: '.0' does not have a name unless the user defines it; similarly, '.-1' does not have a name unless the user defines it. For Flags, negative numbers are supported in order to specify which flags are desired, but the final representation will be zero or positive:

[issue23591] Add Flags and IntFlags

Vedran Čačić added the comment: I think I have written about all the options in detail in http://bugs.python.org/msg272732. If I see it right, your ".0" corresponds to what I called ".__NONE__". It is a "right way" to do it, but for it to be complete, you also have to add ".__ALL__",

[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: The zero value is special in that it represents a flag with nothing set. Excluding it has its own problems, but if you have an argument for that behavior I'm listening. Any other non-Flag value is not allowed, and will raise an error (IntFlags won't share

[issue23591] Add Flags and IntFlags

Vedran Čačić added the comment: So, in fact, your Flags are simply an overlayed namespace over int (the way to give some ints sticky names), and any int is accessible from any Flags, no matter whether it has a name or not? I must say that to me it seems radically different than (Int)Enum

[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: Serhiy's patch is only for IntFlags, and my patch hasn't yet fully incorporated his (many thanks for decompose!) For IntFlags I do not expect to have very many instances alive at once, especially since not-bitwise operators will lose the IntFlag class and

[issue23591] Add Flags and IntFlags

Vedran Čačić added the comment: Yes, IntFlags sidesteps a lot of these issues (though not all: inconsistency with a lot of principles of IntEnum is still jarring). But I thought we were talking about Flags too (it is not in the patch, as far as I see). But now I see that Flags was kinda

[issue23591] Add Flags and IntFlags

Serhiy Storchaka added the comment: You still can use identity testing for named instances of IntFlags. But since the purpose of IntFlags is replacing int flags, tested values can be int (e.g. when read from files as ints). For unknown values you should use either equality testing or wrap

[issue23591] Add Flags and IntFlags

Vedran Čačić added the comment: It's true, but it seems that with Enums, we're trying to retrain people to use identity testing (see https://docs.python.org/3/library/enum.html#comparisons). It would be unfortunate if we had to reuntrain them. :-/ Ethan's proposal (of caching weakrefs) is

[issue23591] Add Flags and IntFlags

Serhiy Storchaka added the comment: I don't think this is a problem. For now os.O_WRONLY is os.O_WRONLY, but os.O_WRONLY|os.O_CREAT|os.O_TRUNC is not os.O_WRONLY|os.O_CREAT|os.O_TRUNC. There is an exponential number of combinations (actually infinite number if count not named bits) and you

[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: Currently, the patch has the main values pre-created (so identity works as expected), and combinations are created on the fly (like normal class instances) -- in which case identity cannot be relied upon. Once I have the basic work done, I'll go back and add a

[issue23591] Add Flags and IntFlags

Vedran Čačić added the comment: I tried to implement this once. The biggest problem I encountered is inconsistency with Enum identity: Enum's main idea is that its objects are pre-created and __new__ just return one of them, so equality is simply identity. If you try to do this with flags,

[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: IntFlags will be in before feature freeze. -- ___ Python tracker ___ ___

[issue23591] Add Flags and IntFlags

Serhiy Storchaka added the comment: Due to dynamic typing EnumSet actually is not needed in Python. You can use sets, tuples or lists for combining enums in new API. IntFlags is needed for old API that already uses ints. I think introducing non-int Flags is overengineering, can't imagine

[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: The idea behind Flags is that they are easily combined enums. The advantage they have over IntFlags is they do not interact with integers, and they cannot have non-existing values used. By keeping the same API as IntFlags we only have two APIs instead of

[issue23591] Add Flags and IntFlags

Serhiy Storchaka added the comment: The name IntFlags is inspired by the Flags attribute in C# (this is the most close concept). The "Int" prefix is added for parallel with IntEnum and because the class behaves as int in some contexts (supports operators |, &, ^, ~ and can be passed to

[issue23591] Add Flags and IntFlags

Ethan Furman added the comment: Flags -> int-backed, but not ints; useful for pure Python flags IntFlags -> ints (like IntEnum); useful for interfacing with other systems Are there better names? -- title: Add IntFlags -> Add Flags and IntFlags ___