Class Browsers vs Static Types (Re: Inefficiency of __getattr__)

Mark Carroll carroll at cis.ohio-state.edu
Thu Oct 5 15:18:34 EDT 2000


In article <uwvfnut23.fsf at ctwd0143.fitlinxx.com>,
David Bolen  <db3l at fitlinxx.com> wrote:
(snip)
>Of course, if it isn't tested, then whether or not you're using a
>statically typed system is only one potential problem that could exist
>in that code.  The fact that static typing might let the compiler
>catch errors in that regard in the non-tested code is only an
>incremental improvement on the chance of that code functioning
>properly once it does get used.

IME it's not all that small. If I'm using a language that does plenty
of static type checking, the compiler catches a very high fraction of
my bugs, at least if the language has a fairly expressive type system
and rarely requires you to do a widening cast or something to get
things done. Quite often, unless there's much code, by the time it
compiles it's working.

>I actually disagree about your every line of code comment.  Perhaps
>not repeatedly in regression tests or automated testing, but I do
>expect every line of code that I write to be executed during
>development at some point - even if I have to write dedicated code to
>do it.  So pretty much the same stuff that the compiler would catch my
>tests will catch.

You obviously missed my qualifier, "Unless you have a very well
designed test suite". Clearly you usually do, but that's too rarely
the case.

>Of course, if it's then impractical for some reason to include such
>tests on official regression/automated testing (not my first choice),
>you still have an exposure of a bug being introduced down the road,
>particularly in a dynamic system, but that's a consequence of having
>the ability to be dynamic, which I'll accept for the benefits.

Indeed. Some applications really benefit from such dynamism.

>>  (...)                                   In particular, with languages
>> like Lisp, without lots of (declare ...)'s I'd sometimes find type
>> errors cropping up some time after the code had been put into use.
>
>Of course, that's not much different from finding semantic or
>behavioral errors cropping up some time after code is in use, but when
>the inputs to the system begin to change.
(snip)

Yes. Most of my bugs happen to be the sort that a type checker will
catch, though. No doubt one's mileage varies.

-- Mark



More information about the Python-list mailing list