[Python-Dev] boxing and unboxing data types

[Serhiy Storchaka]

On 09.03.15 17:48, Neil Girdhar wrote:
> So you agree that the ideal solution is composition, but you prefer
> inheritance in order to not break code?

Yes, I agree. There is two advantages in the inheritance: larger 
backward compatibility and simpler implementation.

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

I don't know and don't want to guess. Let just follow the way of bool 
and IntEnum. When users will be encouraged to use IntEnum and IntFlags 
instead of plain ints we could consider the idea of dropping inheritance 
of bool, IntEnum and IntFlags from int. This is not near future.

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

I afraid that composition will not help you with this. Can numpy array 
pack int-like objects into fixed-width integer array and then restore 
original type on unboxing?