Re: Open Source Quality

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Sun May 09 2004 - 19:49:29 CDT

Note on Arthur's note: The study Doug cited was updated in 1995, using
new tool versions. Still not brand new, but not 14 years.

On May 9, 2004, at 7:59 PM, Karl Auerbach wrote:
> For stations handling bigger numbers, I get concerned about the
> performance of python - at those larger sizes, which tend to be only
> in county and state wide aggregations - I believe that more
> traditional languages and databases will be useful.

Psyco is profound magic. It makes Python rival C in speed, without a
line or two added to turn on the JIT compiler.

But the bottleneck would likely be the database anyway, so I agree that
at a state level we probably shouldn't try to work directly with a huge
batch of XML files. Some kind of relational database (Postgress?
MySQL?) is a good choice for that.

> But I am concerned about Python in that it has what can be a
> dangerously
> flexible name-to-type binding mechanism.

Some conventions might be required, such as explicitly documenting the
use and purpose of each named variable; and using code examination to
make sure no non-compliant assignments occur. Obviously, it's good to
eschew some of the really fancy indirect ways of binding names. But
it's not hard to recognize those dangerous cases (and eliminate them).

PyChecker can help quite a bit. But as Karl says, you have to run it
to make its checks happen.

> And any Python code that manipulates Python's underlying __xxxx__
> variables should be immediately suspect.

Agreed. A somewhat different coding style might be needed for code
that emphasizes provable and auditable properties than in general "as
clever as possible" code.

> Python is good, but it is not a panacea.

Absolutely!
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Mon May 31 23:17:28 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:16 CDT