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

Paul Sokolovsky pmiscml at gmail.com
Wed Apr 30 03:03:52 CEST 2014


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


More information about the Python-Dev mailing list