Is there a "Large Scale Python Software Design" ?

[Michele Simionato]

aleaxit at yahoo.com (Alex Martelli) wrote in message news:<1glwwg1.1hgx2561vflstbN%aleaxit at yahoo.com>...
> That is the book I want to write, the one I have always wanted to write;
> the Nutshell and the Cookbook (and now their second editions) keep
> delaying that plan, but, in a sense, that's good, because I keep
> accumulating useful experiences to enrich those notes, and Python keeps
> growing (particularly but not exclusively in terms of third-party
> extensions and tools) in ways that refine and sometimes indeed redefine
> some key aspects.  To give a simple technical example: I used to have
> substantial caveats in those notes cautioning readers to use multiple
> inheritance in an extremely sparing, cautious way, due to traps and
> pitfalls that made it fragile.  Nowadays, with the advent of 2.3, most
> of those traps and pitfalls have gone away (in the newstyle object
> model), to the point that the whole issue can be reconsidered.
> 

Uhm ... I must say that I was quite keen of Multiple Inheritance
but having seen the (ab)use of it in Zope I am starting questioning 
the wisdom of it. The problem I see with MI (even done well) is that
you keep getting methods from parent classes and each time you have
to think about the MRO and the precedence rules. It is an additional
burden in the programmer's mind. I miss the clean simple concept of 
superclass; the  MRO may be cool but it is not as simple to learn, to
teach
and especially remember. Notice, I am not referring to the algorithm,
it is
not important to remember it; what is disturbing to me is to be aware 
that the resolution of the methods can be non-trivial and that I
should call .mro() each time to check exactly what is happening.
Also 'super' is hard to understand and to use :-(
So, I wonder if Matz was right after all and single inheritance +
mixins
à la Ruby are the right way to go. Yes, from a purist point of view
they are inferior to MI, however from the pragramatist point
of view I don't think you loose very much, and you get a big gain in
short learning curve and expliciteness. Especially 'super' stays
simple.

However I lack experience in Ruby with mixins: do you have experience
or do you know people with experience on that? What they think?
Are they happy with the approach or they wish Ruby had real MI?
Of course in simple systems there is no real issue, I am talking
about large systems. Also, I am not talking about wrong design choice
(for
instance Zope 3 use MI much less than Zope 2: I interpret this as a
recognition that the design was wrong) but in general: assuming you
have
an application where the "right" design is via mixins, is there a real
difference in doing it à la Ruby or with real MI?
It does not look there is a big difference, in practice. 
Yes, you do not have the full power of cooperative methods but you 
also avoid the burden of them and you can always find workarounds; I
would
say there are compensations. 

I have not yet a definite opionion on this point, so I would like to
hear the opinion of others, especially people with real world
experience in complex
systems.

   Michele Simionato