Is there a "Large Scale Python Software Design" ?

[Jonathan Ellis]

Peter Hansen wrote:
> Jonathan Ellis wrote:
> > I haven't jumped into a project of similar size with python, but
the
> > tool support for this approach to working with a large codebase
just
> > isn't there, and I haven't seen any convincing arguments that
> > alternative methodologies are enough better to make up for this.
>
> I'm getting the impression you also haven't tried any significant
> test-driven development.  The benefits of this approach are *easily*
> convincing to most people, and it also fits the bill as removing the
> need for a very sizable portion of the tool support which you rightly
> point out is not there in most tools for dynamically typed languages.

I think I responded to this already --

> > Testing is good; preventing entire classes of errors from ever
> > happening at all is better, particularly when you get large.
Avoiding
> > connectedness helps, but that's not always possible.

Oh yes; so I did. :)  (See my reply to another subthread for one
example of when static type checking saved me a LOT of work.)

What is the biggest system you have built with python personally?  I'm
happy to be proven wrong, but honestly, the most enthusiastic "testing
solves all my problem" people I have seen haven't worked on anything
"large" -- and my definition of large agrees with Alex's; over 100
kloc, more than a handful of developers.

So people don't get me wrong: I love python.  Most of my programming
friends call me "the python zealot" behind my back.  I just don't think
it's the right tool for every problem.

Specifically, in my experience, statically-typed languages make it much
easier to say "okay, I'm fixing a bug in Class.Foo; here's all the
places where it's used."  This lets me see how Foo is actually used --
in a perfect world, Foo's documentation is precise and up to date, but
I haven't worked anywhere that this was always the case -- which lets
me make my fix with a reasonable chance of not breaking anything.
Compile-time type checking increases those chances.  Unit tests
increase that further, but relying on unit tests as your first and only
line of defense is suboptimal when there are better options.

> Having experience with both approaches, and choosing one over
> the other, gives one greater credibility than having experience
> with just one approach, yet clinging to it...

You are incorrect if you assume I am unfamiliar with python.  I readily
admit I have no experience with truly large python projects; I would
classify my the python application I work on as "small," but it seems I
am in good company here in that respect...  I do claim to have fairly
extensive experience with large projects in a statically typed language
(Java).

-Jonathan