Is there a "Large Scale Python Software Design" ?

Jonathan Ellis jbellis at
Tue Oct 19 16:16:01 CEST 2004

Peter L Hansen wrote:
> Jonathan Ellis wrote:
> > 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.
> While it appears true that it is easier to develop certain
> tools for statically typed languages, it's not at all apparent
> that this small benefit outweighs the very significant advantages
> that Python brings to large-scale development, and to large-team
> development.

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 (this is without significant prior
Java experience).  A more-experienced co-worker pointed me in the right
direction, and the IDE did the rest.  ("Find definition," "Find
references.")  Grep can do much the same thing, but painfully slowly --
and inaccurately, when you have a bunch of interfaces implementing the
same method names.  Even after years in the codebase, I still used
these heavily; the codebase grew to about 800 kloc during the 3 years I
worked there.  Developers came and went; even if my memory were good
enough to remember all the code _I_ ever wrote, I'd still have to
periodically repeat the familiarization process with code written by

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'll add "especially when using test-driven
> development and any agile process", and to be perfectly honest
> I'm not sure I would recommend Python nearly as strongly if one
> was forced to use a traditional, non-agile approach to the work.

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.


More information about the Python-list mailing list