[Python-ideas] IntFlags

[Neil Girdhar]

Can I propose that instead of IntFlags, we have IntFields?

class Permissions(IntFields):
    # Some Boolean flags (the bit index)
    owner_read = 0
    owner_write = 1
    owner_exec = 2
    group_read = 3
    group_write = 4
    group_exec = 5
    user_read = 6
    user_write = 7
    user_exec = 8

    # Some named fields (can overlap)
    owner_flags = range(3)
    group_flags = range(3, 6)
    user_flags = range(6, 9)

    # Some field values (can overlap with flags and each other)
    regular_file = range(9), 0o755
    character_file = range(9), 0o664
    directory = range(9), 0o600


And then you can do the following operations:

p = Permissions(Permissions.character_file)

p.set(Permissions.regular_file)

p.owner_write = True

print(p.user_read)

p.owner_flags = 6

Another example:

class IEEE754(IntFields):
    fraction = range(23)
    exponent = range(23, 23+8)
    sign = 31

    denormalized = 'exponent', 0
    infinity = 'exponent', 255

In case it's not clear, there are two kinds of members: named fields and
field values.  Named fields are specified with a range instance or integer
represent the bit range or index.  Field values are specified with a pair,
the first member of which is either a range, an integer, or a string (which
would refer to a declared range); and a second member, which is the value.

IntFields.set accepts a field value name, and sets the bits according to
the value.
IntFields.__setattr__ accepts a named field name; it sets the corresponding
bits according to the value.
IntFields.__getattr__ accepts a named field name or field value name

There is no ~ or & operator.  Something should probably be done for __or__.

Best,

Neil

On Thu, Mar 5, 2015 at 4:25 AM, 'Andrew Barnert' via python-ideas <
python-ideas at googlegroups.com> wrote:

> On Mar 4, 2015, at 15:56, Chris Angelico <rosuav at gmail.com> wrote:
>
> > On Thu, Mar 5, 2015 at 10:42 AM, Andrew Barnert
> > <abarnert at yahoo.com.dmarc.invalid> wrote:
> >> On Mar 4, 2015, at 7:58, Serhiy Storchaka <storchaka at gmail.com> wrote:
> >>
> >>> On 04.03.15 17:31, Chris Angelico wrote:
> >>>> On Thu, Mar 5, 2015 at 2:17 AM, Andrew Barnert
> >>>> <abarnert at yahoo.com.dmarc.invalid> wrote:
> >>>>> Another issue that came up was that C flags often have "combined"
> names that are ambiguous: RDWR = RDONLY | WRONLY), which is fine until you
> want a repr (in C, it's just going to print 3); does it have to be smart
> enough to show RDWR? (Or, worse, RDWR | CLOEXEC.)
> >>>> That could probably be handled by going through the flags in iteration
> >>>> order. If the flag is present, emit it and move on. Something like
> >>>> this:
> >>>
> >>> Yes, something like this, but with iterating flags in descended sorted
> order, and with special case for negative value.
> >>
> >> I think the very fact that the two of you immediately knew which order
> was obvious, but you chose the opposite one as the obvious one, proves that
> it's not obvious.
> >
> > Actually, we chose the same thing, only in slightly different ways.
> > Serhiy suggested (in effect) sorting the flags by value and stepping
> > through from highest to lowest, which enforces that the combined flags
> > will be the ones picked. I suggested putting the responsibility onto
> > the class author - if you want the combined ones to be used, place
> > them first - which is like how aliasing works (the first one with a
> > given value is used in str/repr, any others are aliases). That's a
> > relatively minor point, and it depends on whether there'd ever be a
> > time when you want to provide a combined flag that _isn't_ used in
> > str/repr; if there is, you need my plan, but if not, go with the
> > simpler route.
>
> Except with yours, any time you copy the definition (whether by hand, or
> with an automated tool) from C, where the combined ones almost always come
> last, they won't be used; with his, they will. So, in the most common use
> case, you'll get the opposite result.
>
> (Of course if you always pick the _last_ instead of the first or the
> highest, which gives you the choice for the rare case, but the nice answer
> for the ubiquitous case. That breaks your analogy with aliases, but it does
> work the same way as normal class attributes, where the last value wins...)
> _______________________________________________
> 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/
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/python-ideas/L5KfCEXFaII/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> python-ideas+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150305/99bf6cda/attachment-0001.html>