does lack of type declarations make Python unsafe?

[Alex Martelli]

Peter Hansen wrote:

> beliavsky at aol.com wrote:
>> 
>> In Python, you don't declare the type of a variable, so AFAIK there is
>> no way for the interpreter to check that you are calling functions
>> with variables of the correct type.
> 
> This whole discussion has taken place, repeatedly, in the past,
> so if you would like to check the archives you'll find a few
> dozen versions of the question and the lengthy threads that ensued.

Absolutely true.  Moreover, the same discussion also takes place very
often outside of this group, as dynamic-typing languages grown in
scope and importance.  For example, here's the discussion on this
issue started by Robert Martin (well-known OO guru, former editor of
C++ Report, etc, etc): "Are Dynamic Languages Going to Replace Static
Languages?", http://www.artima.com/weblogs/viewpost.jsp?thread=4639 ...:

"I've been a statically typed bigot for quite a few years ... type issues
simply never arose. My unit tests kept my code on the straight and narrow.
I simply didn't need the static type checking that I had depended upon for
so many years ... the flexibility of dynamically typed langauges [sic] makes
writing code significantly easier."

Be sure to follow the heated 65-comments ongoing discussion, of course.

In a very similar vein, Bruce Eckel (best-selling author of books about
C++ and Java, and a long-time Python fan) at "Strong Typing vs. Strong
Testing", http://mindview.net/WebLog/log-0025 ...:

"To claim that the strong, static type checking constraints in C++, Java, or
C# will prevent you from writing broken programs is clearly an illusion
(you know this from personal experience). In fact, what we need is 

Strong testing, not strong typing.

So this, I assert, is an aspect of why Python works. C++ tests happen at
compile time (with a few minor special cases). Some Java tests happen at
compile time (syntax checking), and some happen at run time (array- bounds
checking, for example). Most Python tests happen at runtime rather than at
compile time, but they do happen, and that's the important thing (not
when)."


Note the commonality: "unit tests", "strong testing".  Halfways decent
unit-tests will catch all the type-errors that a typical statically-typed
language would catch *and then some*.  Without unit-tests your code is
untrustworthy anyway (both Robert and Bruce make the point forcefully!),
while, WITH good unit-tests, type issues "simply never arise" as Robert
Martin puts it.

BTW, I strongly recommend Kent Beck's "Test-Driven Development by Example"
(Addison-Wesley) -- short and to the point.


>> Calling functions with invalid arguments is one of the commonest
>> programming errors
> 
> Debatable.  Not true in my experience.

Pretty true in my own experience, for a suitably generalized definition
of "functions" that includes operators and other callables.  However,
the reasons the arguments are "invalid" are more often connected to the
*values* that those arguments take at runtime, rather than to the types
of those arguments (which might be checkable at compile time if one
used a statically-typed language), therefore this is not an argument
in favour of static type-checking.  E.g., indexing blah[bloh] with an
invalid index value computed in variable bloh (invalid with respect
to the set of indices that container blah can accept) is, alas, far
from rare; but it's not a type-checking issue, and rarely will a
compiler be able to deduce reliably that the value of bloh as run-time
computed is going to be invalid.  Thus, runtime checks are needed here
(Java does them, Python does them, C++ may or may not do them) -- AND
unit-tests that you can trust to tickle any bugs that might be there...



Alex