[Python-ideas] IntFlags

[Eugene Toder]

On Thu, Mar 5, 2015 at 12:20 PM, Luciano Ramalho <luciano at ramalho.org>
wrote:

> On Thu, Mar 5, 2015 at 2:14 PM, Eugene Toder <eltoder at gmail.com> wrote:
> > The flags discussed so far are unordered as well. E.g. OpenMode.RDONLY |
> OpenMode.WRONLY | OpenMode.CLOEXEC == OpenMode.RDONLY | OpenMode.CLOEXEC |
> OpenMode.WRONLY or any other permutation. In other words, flags (aka
> bitmasks) are just an optimized representation of an (unordered) set of
> small integer values.
>
> I agree that they are unordered in the common use cases. But the kind
> of low-level code where such flags are used often involves building a
> byte or a word out of those flags to pass to a low-level C API. How do
> you make sure that the byte you will build makes sense if you don't
> care about the position, or the log2 of each flag value? So I
> definitely think ordering and positioning are to be preserved in a
> data structure intended to manage and combine bits.
>
I think you conflate the two separate issues: ordering of the elements in
the set, and the bit representation of the set. Flags don't preserve the
former, but guarantee the later. Normal sets don't preserve the former too,
and the latter doesn't make sense for them. BitSet would not preserve the
former, but add the later in the way compatible with flags. Specifically,
when you define a BitSet, you assign every possible element a specific bit
position (i.e. integer value). When you perform bit operations the natural
thing happens, and you get the expected bit representation.

Eugene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150305/578dd76b/attachment-0001.html>