[Python-Dev] boxing and unboxing data types

Neil Girdhar mistersheik at gmail.com
Mon Mar 9 21:49:27 CET 2015


On Mon, Mar 9, 2015 at 12:54 PM, Serhiy Storchaka <storchaka at gmail.com>
wrote:

> 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.
>
>
Inheritance might be more backwards compatible, but I believe that you
should check how much code is genuine not restricted to the idealized flags
interface.   It's not worth talking about "simpler implementation" since
the two solutions differ by only a couple dozen lines.

On the other hand, composition is better design.  It prevents you from
making mistakes like adding to flags and having carries, or using flags in
an unintended way.


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


I think it's the other way around.  You should typically start with the
modest interface and add methods as you need.  If you start with full blown
inheritance, you will find it only increasingly more difficult to remove
methods in changing your solution.  Using inheritance instead of
composition is one of the most common errors in objected oriented
programming, and I get the impression from your other paragraph that you're
seduced by the slightly shorter code.  I don't think it's worth giving in
to that without proof that composition will actually break a significant
amount of code.

Regarding IntEnum — that should inherit from int since they are truly just
integer constants.  It's too late for bool; that ship has sailed
unfortunately.


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


You're right.

>
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> mistersheik%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150309/d88d8da0/attachment-0001.html>


More information about the Python-Dev mailing list