Is there a "Large Scale Python Software Design" ?

Peter Hansen peter at
Wed Oct 20 02:40:24 CEST 2004

Jonathan Ellis wrote:
> Almost four years ago I started working at a company with about 500
> kloc of Java code.  Thanks largely to tool support I was able to get in
> and start fixing bugs my first day [...snip rest of anecdote]

These are all things that don't really seem to be issues with the
approach to development that I use, so I can't really say anything
except that perhaps it's possible to approach development in such
a way that you won't miss such tools.  I've entirely given up on
fancy IDEs, and believe I'm more productive without than I ever
was with.

> 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.

> 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.

I think I can sum up everything I have to say on this subject with
the following:

Most people who adopt Python (and I'm pretty sure *all* those
who use it for large projects) have worked with at least one
other language, often statically typed languages.

Yet they now use Python.

Most people who adopt test-driven development have worked with
at least one other approach to programming, usually those heavily
dependent on good tool support.

Yet they now use TDD.

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...


More information about the Python-list mailing list