[Python-ideas] IntFlags

[Neil Girdhar]

On Sat, Mar 7, 2015 at 3:38 PM, Ethan Furman <ethan at stoneleaf.us> wrote:

> On 03/07/2015 12:28 PM, Georg Brandl wrote:
> > On 03/07/2015 04:05 PM, Ethan Furman wrote:
> >
> >>>> As long as we are dreaming  :)
> >>>>
> >>>> class Stat(IntFlag):
> >>>>    RDONLY = 1
> >>>>    NOSUID = 2
> >>>>    NODEV = 4
> >>>>    NOEXEC = 8
> >>>>    SYNCHRONOUS = 16
> >>>>    MANDLOCK = 64
> >>>>    WRITE = 128
> >>>>    APPEND = 256
> >>>>    NOATIME = 1024
> >>>>    NODIRATIME = 2048
> >>>>    RELATIME = 4096
> >>>>
> >>>> a = Stat.RDONLY  # creates a new instance of Stat, not a singleton
> >>>
> >>> Why?
> >>
> >> Because by having mutable instances of Stat we can have more Python
> operations:
> >>
> >> instead of:
> >>
> >>   x = Stat(some_Stat_value_from_somewhere)
> >>   x = x | Stat.NOEXEC  # to set the bit
> >>
> >> we can say:
> >>
> >>   x = Stat(some_Stat_value_from_somewhere)
> >>   x.NOEXEC = True
> >
> > Please no.  You're making a mutable type out of something that is
> conceptually
> > (and in people's minds) an integer.  Remember how long it can take to
> understand
> > that
> >
> > a = 1
> > a = 2
> >
> > does not change the integer "1" to now be "2".
>

The fact that the flags are stored in an int — that is, the implementation
has nothing at all to do with the conceptual nature of flags.  Flags are
properties.  Your knowledge of the underlying implementation is misleading
you.  It would be just as easy and intuitive to implement those flags as
keys and values in a dict.

If flags were conceptually subtypes of int, then you should be able to do
things like:

flags ** 7

or

flags // 91

Do you agree that this is totally meaningless?  There is no "is a"
relationship between Flags and int.  There is a conversion between the
conceptual mapping that is a Flags object to int for the sole purpose of
calling into APIs.


> Good point.  To do something like that the name would have be BitFlags or
> something no so solidly tied to "immutable".
> At any rate, for this to work would require `int(x)` around every call to
> a lower-level API, and that's a non-starter.
>

Correct me if I'm wrong, but doesn't Boost.Python when generating Python
methods that accept ints, automatically call __int__ on the arguments.
Doesn't SWIG do the same?  Can you give me some examples of methods that
accept ints but don't call __int__?  It seems to me to be a bug in those
methods than in the caller.  A method that wants an int should call __int__
on its argument — not expect that isinstance(X, int) etc.


>
> --
> ~Ethan~
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150308/b9ffe14f/attachment.html>