[Python-Dev] boxing and unboxing data types

[Neil Girdhar]

Totally agree
On 9 Mar 2015 19:22, "Nick Coghlan" <ncoghlan at gmail.com> wrote:

>
> On 10 Mar 2015 06:51, "Neil Girdhar" <mistersheik at gmail.com> wrote:
> >
> >
> >
> > 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.
>
> We literally can't do this, as the vast majority of Python code in the
> world is locked up behind institutional firewalls or has otherwise never
> been published. The open source stuff is merely the tip of a truly enormous
> iceberg.
>
> If we want to *use* IntFlags in the standard library (and that's the only
> pay-off significant enough to justify having it in the standard library),
> then it needs to inherit from int.
>
> However, cloning the full enum module architecture to create
> flags.FlagsMeta, flags.Flags and flags.IntFlags would make sense to me.
>
> It would also make sense to try that idea out on PyPI for a while before
> incorporating it into the stdlib.
>
> Regards,
> Nick.
>
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > 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/ncoghlan%40gmail.com
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150309/7b975664/attachment-0001.html>