Is there a "Large Scale Python Software Design" ?

[Dave Brueck]

Jonathan Ellis wrote:
> Andrea Griffini wrote:
> 
>>I did it.
>>
>>I proposed python as the main language for our next CAD/CAM
>>software because I think that it has all the potential needed
>>for it. I'm not sure yet if the decision will get through, but
>>something I'll need in this case is some experience-based set
>>of rules about how to use python in this context.
>>
>>For example... is defining readonly attributes in classes
>>worth the hassle ? Does duck-typing scale well in complex
>>software or should I go for a classic inheritance hierarchy ?
>>
>>In other words... is there something like the classic "Large
>>Scale C++ Software Design" (Lakos) for python ? I'm not
>>looking for a bible, but lessons learned from someone that
>>already went down this path could be quite interesting.
> 
> 
> Wouldn't it have been better to ask these questions BEFORE proposing
> python as (presumably) a Great Solution?  IMO, as great as python is,
> it isn't appropriate for projects that are large and include many
> developers.

The OP would be well-advised to search the Google archives of c.l.py as many 
(myself included) take the contrarian view - as the project grows in size it is 
harder to justify going with "classic" languages like C++, or even Java - the 
associated costs at each stage of the project are relatively larger to begin 
with, and grow more quickly as well.

> The benefits of static typing, not least among which is the vastly
> superior ease of creating tools that "understand" the language,
> outweigh python's advantages in an environment when many people are
> writing a lot of code.

I'm not so sure - how much of the benefit those "smart" tools provide goes to 
helping the developer manage complexity caused by the language itself? It seems 
that often (not always, of course) a lot of what they do is help the programmer 
manage oodles of little details that the programmer ought not be burdened with 
in the first place, _especially_ on large projects.

What specifically do you see breaking down if Python is used in a project with 
lots of people? From working on large projects with lots of people, I've noticed 
that projects naturally get divided into components as different teams work on 
them, regardless of the language (so for any given piece of code, the percentage 
of the total programmers touching that piece of code drops, not rises, as the 
total size of the development staff goes up). Again, regardless of language, 
large projects & teams almost force well-defined interface points between 
various components - I don't see how Python would be any hinderance at all.

On the plus side, projects implemented in higher level languages grow more 
slowly (and thus become unmanageable more slowly) than would projects 
implemented in lower-level languages. The list goes on and on - I've found 
Python components generally easier to test than, say, C++ components. It's also 
easier for more people to comprehend more of the code (and, in turn, more of the 
implications of decisions), etc., etc.

-Dave