[Python-Dev] boxing and unboxing data types

[Neil Girdhar]

On Mon, Mar 9, 2015 at 11:11 AM, Serhiy Storchaka <storchaka at gmail.com>
wrote:

> понеділок, 09-бер-2015 10:18:50 ви написали:
> > On Mon, Mar 9, 2015 at 10:10 AM, Serhiy Storchaka <storchaka at gmail.com>
> wrote:
> > > понеділок, 09-бер-2015 09:52:01 ви написали:
> > > > On Mon, Mar 9, 2015 at 2:07 AM, Serhiy Storchaka <
> storchaka at gmail.com>
> > > > > And to be ideal drop-in replacement IntEnum should override such
> methods
> > > > > as __eq__ and __hash__ (so it could be used as mapping key). If
> all methods
> > > > > should be overridden to quack as int, why not take an int?
> > > >
> > > > You're absolutely right that if *all the methods should be
> overrriden to
> > > > quack as int, then you should subclass int (the Liskov substitution
> > > > principle).  But all methods should not be overridden — mainly the
> methods
> > > > you overrode in your patch should be exposed.  Here is a list of
> methods on
> > > > int that should not be on IntFlags in my opinion (give or take a
> couple):
> > > >
> > > > __abs__, __add__, __delattr__, __divmod__, __float__, __floor__,
> > > > __floordiv__, __index__, __lshift__, __mod__, __mul__, __pos__,
> __pow__,
> > > > __radd__, __rdivmod__, __rfloordiv__, __rlshift__, __rmod__,
> __rmul__,
> > > > __round__, __rpow__, __rrshift__, __rshift__, __rsub__, __rtruediv__,
> > > > __sub__, __truediv__, __trunc__, conjugate, denominator, imag,
> numerator,
> > > > real.
> > > >
> > > > I don't think __index__ should be exposed either since are you
> really going
> > > > to slice a list using IntFlags?  Really?
> > >
> > > Definitely __index__ should be exposed. __int__ is for lossy
> conversion to int
> > > (as in float). __index__ is for lossless conversion.
> >
> > Is it?  __index__ promises lossless conversion, but __index__ is *for*
> > indexing.
>
> I spite of its name it is for any lossless conversion.
>

You're right.

>
> > > __add__ should be exposed because some code can use + instead of | for
> > > combining flags. But it shouldn't preserve the type, because this is
> not
> > > recommended way.
> >
> > I think it should be blocked because it can lead to all kinds of weird
> > bugs.  If the flag is already set and you add it a copy, it silently
> spills
> > over into other flags.  This is a mistake that a good interface prevents.
>
> I think this is a case when backward compatibility has larger weight.
>
>
So you agree that the ideal solution is composition, but you prefer
inheritance in order to not break code?  Then,I think the big question is
how much code would actually break if you presented the ideal interface.  I
imagine that 99% of the code using flags only uses __or__ to compose and
__and__, __invert__ to erase flags.


> > > For the same reason I think __lshift__, __rshift__, __sub__,
> > > __mul__, __divmod__, __floordiv__, __mod__, etc should be exposed too.
> So the
> > > majority of the methods should be exposed, and there is a risk that we
> loss
> > > something.
> >
> > I totally disagree with all of those.
> >
> > > For good compatibility with Python code IntFlags should expose also
> > > __subclasscheck__ or __subclasshook__. And when we are at this point,
> why not
> > > use int subclass?
> >
> > Here's another reason.  What if someone wants to use an IntFlags object,
> > but wants to use a fixed width type for storage, say numpy.int32?   Why
> > shouldn't they be able to do that?  By using composition, you can easily
> > provide such an option.
>
> You can design abstract interface Flags that can be combined with int or
> other type. But why you want to use numpy.int32 as storage? This doesn't
> save much memory, because with composition the IntFlags class weighs more
> than int subclass.
>
>
Maybe you're storing a bunch of flags in a numpy array having dtype
np.int32?  It's contrived, I agree.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150309/9599b068/attachment.html>