> > > Furthermore, I have added a mechanism for testing. Both for testing
> > > individual modules and executing recipes. The typeless nature of Python
> > > requires doing a lot of tests. Only a few have been added so far, but
> > > one bug has already been detected.

I'd highly recommend implementing a testing discipline in your process
up front. On SCons, we have a policy (adopted from and enforced by
Aegis) that every checkin must be accompanied by one or more new or
changed tests that demonstrate the bug or feature by failing on the old
code base. By building up our tests incrementally, we now have a very
complete set of unit tests for our modules, and a regression test suite
of 163 end-to-end tests.

I've found this way of working to be especially crucial during the early
stages of development, when you may need to refactor parts of the design
frequently as you add features. Being able to do this and *know* you
haven't broken anything because all of the tests pass (a la eXtreme
Programming) is invaluable.

> > Isn't the typeless nature of python a problem when you try to build
> > good solid code? I don't like the Java - we do the checks runtime and
> > generate an exception when something goes wrong - attitude. You can't
> > have a 100% test coverage. I like the C++ way - strong typechecking,
> > we don't want to loose performance runtime - better. Do you need
> > lint-like tools to overcome the typeless nature of Python, or is your
> > code 80% error recovery, 20% functionality?
>
> It's true that Python leaves most of the testing to the user. The
> largest potential problem I see is using a function that wasn't imported
> and passing a variable of the wrong type to a function. This can only
> be checked with a large set of tests. Mostly written with one eye on
> the code and making sure each line is used at least once in a test.

Python will throw an exception if you try to use a function that hasn't
been imported. It won't throw an exception just because you pass a
variable of the wrong type, but it will if/when you try to use that
variable inappropriately.

In practice, we've found that the ongoing challenge is to not just rely
on generic exception-handling, which is great for programmer debugging,
but to catch exceptions at all of the appropriate points and provide
error messages more helpful for less sophisticated end-users.

> Perhaps some kind of Python-lint exists, I haven't looked for it yet.

Look for PyChecker, available on SourceForge. It finds a number of
problems in Python code by performing analysis on the compiled byte
code.

--SK