[Python-ideas] IntFlags

[Andrew Barnert]

On Mar 4, 2015, at 7:51, Neil Girdhar <mistersheik at gmail.com> wrote:

> For ~, I suggest either having an extra bit on the object that remembers negation

Then what exactly happens when you & or | two values, one of which has the negation bit set? For example, using stat values, what is S_IRUSR & ~S_IXUSR? Or, worse, with |. You can end up with some bits set, some negatively set, and some set neither way. How are you going to represent that?

In C, because the values are stored as unsigned fixed-size (say, 16-bit) ints and the ~ is just the usual 1's complement operator on unsigned int types, ~S_IXUSR is all the bits except 0o400 (that is 0o1377).

There are multiple ways to solve this: 

 * Use signed 1's complement (as I suggested in my original message, which Serhily ignored and suggested the same thing), but then the value of ~S_IXUSR is -0o401, which isn't likely to match == to a value you got from C (or to be obvious to someone using/debugging the code).

 * Scan the values and assume the highest bit seen is the max bit (as two other people suggested) and manually unsigned-1's-comp, but this is not only more complicated, it only provides the same values as C if you've used all 8/16/32/64 bits or you explicitly mask off & ALL_BITS at the end.

 * Require specifying the max bit somewhere in the definition, maybe defaulting to 32, or maybe using C++ enum rules (round the highest value up to 8, 16, 32, or 64 bits).

 * Store two separate ints, one for negated and one for non-negated.

 * Don't allow ~ at all (as you suggest at the end of the paragraph), using methods instead (although you only gave mutating methods, which is going to make a lot of C 1-liners turn into verbose 3-liners in Python).

And if you're wondering why I keep harping on having the same value as C: if you don't care about that, you don't need to use an int as a bitset in the first place; the only reason this proposal is useful in the first place is that functions like stat return ints that have well-known meanings from C, and everyone knows how to manipulate them in C, and we want to be able to do the same thing in Python but with readable reprs and all the other benefits of a real enum type.

> or replacing the patterns a &= ~b with a.clear_flags(b) and a & ~b with a.without_flags(b) or something like that.
> 
> On Tuesday, March 3, 2015 at 10:54:15 AM UTC-5, Serhiy Storchaka wrote:
>> 
>> Enum and IntEnum classes allow constants to have nice str() and repr() 
>> representations. 
>> 
>>  >>> socket.AF_INET 
>> <AddressFamily.AF_INET: 2> 
>>  >>> socket.socket() 
>> <socket.socket fd=3, family=AddressFamily.AF_INET, 
>> type=SocketKind.SOCK_STREAM, proto=0, laddr=('0.0.0.0', 0)> 
>> 
>> But when integer constants are flags that should be ORed, IntEnum  
>> doesn't help, because the result of bitwise OR of two IntEnum instances 
>> is int, and this value can't be represented as IntEnum. 
>> 
>> We need new type IntFlags. It is like IntEnum, but has differences: 
>> 
>> 1. The value of an instance should be not limited to the set of 
>> predefined constants. It can be a combination of predefined constants or 
>> even arbitrary integer. 
>> 
>> 2. The result of "|", "&" and "~" operators for IntFlags arguments 
>> should be an instance of the same IntFlags subclass. 
>> 
>> 3. It should have nice str() and repr(). 
>> 
>>  >>> print(stat.S_IROTH | stat.S_IWOTH) 
>> stat.S_IROTH|stat.S_IWOTH 
>>  >>> stat.S_IROTH | stat.S_IWOTH 
>> <StatFlags.S_IROTH|S_IWOTH: 6> 
>> 
>> Any thoughts? 
>> 
>> _______________________________________________ 
>> Python-ideas mailing list 
>> Python... at python.org 
>> https://mail.python.org/mailman/listinfo/python-ideas 
>> Code of Conduct: http://python.org/psf/codeofconduct/ 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150304/9b5f4d67/attachment.html>