[Python-ideas] IntFlags

[Neil Girdhar]

This is exactly why we should not have & and ~.  It creates the possibility
to write meaningless code.  Have methods that clear fields and methods that
set them.  I proposed an interface to IntFields in another message.



Best,

Neil

On Wed, Mar 4, 2015 at 5:59 PM, Andrew Barnert <abarnert at yahoo.com> wrote:

> 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).
>

(I did give a pair of methods one of which was not mutating)


> 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/20150305/8068165f/attachment.html>