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 <pmis...@gmail.com> wrote:
> Hello,
>
> On Tue, 29 Apr 2014 10:47:26 -0400
> PJ Eby <p...@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:pmis...@gmail.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@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)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
