[Python-Dev] Multiple inheritance from builtin (C) types [still] supported in Python3?

[Guido van Rossum]

When I redesigned and reimplemented this part of Python inheritance
(somewhere in the 2.1 - 2.3 time frame, I forget the exact timing) I was
well aware of the C++ approach and decided against it, preferring an
approach requiring less compiler assistance that was easier for C
programmers to use and understand. If as a Python programmer you want a
more general multiple inheritance, you just shouldn't use slots. As a C
programmer writing extension modules, the single-inheritance model (which
this effectively is, at that level) is much easier to deal with.


On Tue, Apr 29, 2014 at 6:03 PM, Paul Sokolovsky <pmiscml at gmail.com> wrote:

> Hello,
>
> On Tue, 29 Apr 2014 10:47:26 -0400
> PJ Eby <pje at telecommunity.com> wrote:
>
> []
> >
> > From memory of the last time I dealt with this, the rules were that
> > you could mix two classes only if their __slots__ differed from their
> > common __base__ by *at most* __dict__ and/or __weakref__.  The dict
> > and weakref slots are special, in that the type structure contains
> > their offsets, which makes them relocatable in subclasses.  But any
> > other __slots__ aren't relocatable in subclasses, because the type
> > structure doesn't directly keep track of the offsets.  (The slot
> > descriptors do.)
> >
> > But I don't think there's anything in principle that requires this,
> > it's just the implementation.  You could in theory relocate __slots__
> > defined from Python code in order to make a merged subclass.  It's
>
> Ok, so one can gather from this that __slot__'ed class can't be used as
> multiple bases, as in this example:
>
> class B1:
>     __slots__ = ('a', 'b')
>
> class B2:
>     __slots__ = ('a', 'b', 'c')
>
> class C(B2, B1):
>     pass
>
> > just that the effective "__slots__" of C code can't be moved, because
> > C code is expecting to find them at specific offsets.  Therefore, if
> > two types define their own struct fields, they can't be inherited
> > from unless one is a subtype of the other.
>
> Well, here it itches to ask if C++-like offsetting of subclass to base
> class "this" pointer was considered, but I already feel like a child
> asking all those stupid questions. One obvious answer would be that
> there's little point to complicate the matter, as it's just emulation
> of inheritance via enclosing, and explicit enclosing offers more
> flexibility anyway (but then it's less efficient).
>
> []
>
> > That is not a precise description of the algorithm, but that's the
> > gist of how it works.  __base__ is a slot on the type object and is
> > tracked at the C level in order to sort out layouts like this.
>
> Thanks much for the detailed description, will serve as a good
> reference when in MicroPython we'll hit actual case when CPython
> accepts some inheritance patterns and uPy doesn't.
>
>
> --
> Best regards,
>  Paul                          mailto:pmiscml at gmail.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/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140429/ce784a4f/attachment.html>