Mixin class data

[Paul Moore]

Greg Ewing <see_reply_address at something.invalid> wrote in message news:<3DA4B561.1040906 at something.invalid>...
> Paul Moore wrote:
> 
> > I'd rather not make it a requirement of
> > this particular mixin that the derived class call its __init__ routine
> 
> 
> Why not? It seems perfectly reasonable to me that
> if you inherit something you should be responsible
> for making sure it's initialised properly.

Mainly because the normal use will be to define a derived class wich
is nothing more than an accumulation of the base and the required
mixins. So the user will normally do:

class MyClass(B, M1, M3):
    pass

Having to say (in effect):

"""If you use mixin M2, you need to define an __init__ like

    def __init__(self):
        B.__init__(self)
        M2.__init__(self)

but for all other mixins, you don't need an __init__ of your own"""

seems contrived, at best...

In practice, B is a subclass of StreamRequestHandler which handles
incoming requests and breaks them into command/argument pairs. The
mixins then provide handlers for the standard commands (and callback
to the *server* subclass for implementation, available as self.server,
rather than to the derived handler class). Given that extending TCP
protocols is not normal, the user class ends up being a behaviourless
accumulation of mixins.

Maybe I'm abusing (multiple) inheritance here, by overusing the mixin
concept. But I recall this style well from other languages (notably
OakLisp, an object-oriented Scheme dialect) where it worked extremely
well.

Paul.