does lack of type declarations make Python unsafe?
dave at boost-consulting.com
Mon Jun 16 17:59:47 CEST 2003
"Donn Cave" <donn at drizzle.com> writes:
> Quoth danb_83 at yahoo.com (Dan Bishop):
> | beliavsky at aol.com wrote in message news:<3064b51d.0306151228.22c595e0 at posting.google.com>...
> |> Thus, if I define a function correl(x,y) to compute the correlation of
> |> two vectors, which makes sense to me only if x and y are 1-D arrays of
> |> real numbers,
> | But what kind of real numbers? IEEE double-precision? Or might you
> | someday need a correl function that works with ints (e.g., to compute
> | Spearman's correlation coefficient), or arbitrary-precision floats, or
> | BCD numbers, or rational numbers, or dimensioned measurements?
> | As long as your number classes have +, -, *, /, and __float__ (so
> | math.sqrt works) defined correctly, you don't have to rewrite your
> | correl code to support them. THAT is the beauty of dynamic typing.
> Or the beauty of static typing. In a rigorously statically typed
> language like Haskell, you'd write your function more or less the
> same as you would in Python, but the compiler would infer from the
> use of +, -, etc. that its parameters are of type Num, and you would
> be expected to apply the function to instances of Num - any numeric
> type. Anything else is obviously an error, and your program won't
> compile until it makes sense in that respect.
> One would think from reading this thread that this would be good
> for safety but hard to program for, but it's actually the opposite.
> I'm told that type checking is practically irrelevant to safety
> critical standards, because the testing needed to meet standards
> like that makes type correctness redundant. But the compiler cleans
> up lots of simple errors when you're writing for more casual purposes,
> and that saves time and possibly embarrassment.
I find that static typing makes a big difference for two things:
1. Readability. It really helps to have names introduced with a
type or a type constraint which expresses what kind of thing they
are. This is especially true when I am coming back to code after
a long time or reading someone else's work. Attaching that
information to the name directly is odious, though, and leads to
abominations like hungarian notation.
2. Refactoring. Having a compiler which does some static checking
allows me to make changes and use the compiler as a kind of
"anchor" to pivot against. It's easy to infer that certain
changes will cause compiler errors in all the places where some
corresponding change needs to be made. When I do the same thing
with Python I have to crawl through all the code to find the
changes, and a really complete set of tests often take long
enough to run that using the tests as a pivot point is
More information about the Python-list