Is there a "Large Scale Python Software Design" ?
jbellis at gmail.com
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
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