From: scott at chronis.pobox.com (scott cotton)
Date: 27 May 1999 04:03:43 GMT
Subject: Python Scalability
References: <7i9l2l$5fu@world1.bellatlantic.net> <7ignk0$k18$1@nnrp1.deja.com> <7igu3d$3db$1@cronkite.cc.uga.edu> <7iic8e$rgt$1@nnrp1.deja.com>
Message-ID: <slrn7kph7j.48d.scott@chronis.pobox.com>
Content-Length: 1075
X-UID: 1889                                                 

On Thu, 27 May 1999 02:56:15 GMT, dacut at kanga.org <dacut at kanga.org> wrote:
>And, frankly, this is all that you really need.  Just something to flag
>silly errors that may be difficult/tedious to test at run time.

There are indeed lots of these errors in the development of
medium/largish python apps.  The approach I've taken is to
integrate testing with development, on a fine-grained
level.  I begin testing code as soon as it is testable, and
then make sure that I test all of it.  If you make this a
regular habit, it becomes a bit less tedious.  You should
try the doc-string testing code that Tim Peters put up on
the python contributed ftp site, as one way to do this.

While this stuff may not be as easy to do with a gui like
TKinter, it can sure beat tracebacks a mile long that arise
from overall testing.  And if you're using emacs,
hippie-expand won't make typos while remembering names like
you and I do.  

There are some things you can do to make python more
scaleable without an entire optional typing system -- though
that'd be nice too.

scott






