__slots__ and multiple inheritance

[Bengt Richter]

On Sat, 14 Dec 2002 15:53:45 -0500, Carl Banks <imbosol at vt.edu> wrote:

>Dave Reed wrote:
>> 
>> __slots__ doesn't seem to work as I expect when I use mixins/multiple
>> inheritance:
>> 
>> I've got a BaseSQL class (see code at bottom of message) in which I
>> define __slots__ (I started using it so pychecker didn't complain
>> about me using the instance variables from the other base class). I
>> left out "values" from __slots__, but it still lets me assign to
>> self.values.
>> 
>> Also, If I put the same __slots__ in the StudentSQL class, I get the
>> error:
>> 
>>    class Student(BaseSQL, StudentSQL):
>> TypeError: multiple bases have instance lay-out conflict
>> 
>> Can anyone explain to me how this should work?
>
>It doesn't work at all.  It seems kind of stupid at first, but you
>can't inherit from two classes with slots (well, unless those classes'
>slots are all inherited from a common base class).
>
>The reason for this is that slots have fixed positions in the object's
>low-level structure.  One base class puts its slots at position x in
>the structure; another base class also puts slots at position x.  You
>can't multiply inherit from both of them because of the clash.
>
This triggers a thought:

ISTM __xxx__ primarily serves as an object definition metalanguage (1).
I.e., we use it to compose objects with standard behaviours and attributes
used implicitly in higher level constructs.  Perhaps moving towards using
__xxx__ purely for that primary purpose would be a good thing?

1. standard primitive object attributes
2. compiler hints/directives
    2.1 allocation-related
    2.2 metaclass linkage
3. import/loader hints/directives
4. ?

I.e. __slots__ seems effectively an optimization hint (actually directive, I guess).
Or is the restriction above a design intent rather than a necessary side effect?

Regards,
Bengt Richter