does lack of type declarations make Python unsafe?

[Brandon Corfman]

Steven Taschuk wrote:
> Quoth Brandon Corfman:
> 
>>1) Why can't this issue be solved by making Python like Lisp/Dylan in 
>>this regard? Make type declarations/range limitations on variables an 
>>optional thing. Flexibility if you need it, safety later if you're 
>>concerned about it.
> 
> 
> This was discussed in the now-defunct types-sig, if memory serves.
>     <http://www.python.org/sigs/types-sig/>
> I've never looked into it, but I imagine the archived discussions
> there might shed some light on why this hasn't been done.
> 
Wow, what a snarl those discussions are. I don't think I have enough 
time to track down all the reasons why static typing didn't make it, but 
the effort seemed to be reduced to checking interfaces as opposed to 
types, which seems very limited IMO.

> 
>>2) It also seems that the Python community wastes too much time on these 
>>explanations. A better answer (in my mind) would be to say that the 
>>Python environment is designed to make the development process far 
>>different than in a statically-typed language like C++.
> 
> 
> That seems like a good answer (though I don't think it replaces
> the other explanations in the thread so much as it augments or
> summarizes them).
> 
> As for us wasting our time with these explanations, well, the
> usual solution (such as it is) would be to write up a FAQ entry
> and direct future querents to it.  Would you like to write one?
> 
>   [...]

I could try. I'm unsure what the community consensus is though. Was my 
post really a true summary/augmentation of the discussion on type 
safety? I think the official answer is more like the following:
1) type errors are not all that common.
2) writing good unit tests will prevent type errors (as well as many 
others) since the errors will be discovered during development. 
Therefore, use a test-first methodology.
3) dynamic typing allows other dynamism/flexibility in the language, 
i.e. if a function behaves correctly for a known set of classes/data 
types, then the function can also allow other unknown classes/types to 
be used if the types exhibit compatible behavior.
4) Python has a mechanism for dealing with type errors: exceptions.

The counterarguments are:
1) Type errors are common, and even if they aren't the _most_ common, so 
what -- shouldn't the compiler/interpreter assist with this anyway?
2) Unit tests are fine, but developers can't always foresee all the 
possible test cases they will need.
3) Specifying types for variables is a lot simpler than the other 
checking alternatives (exceptions, unit tests).
4) Losing a few dynamic features and gaining increased safety is an 
acceptable tradeoff.

What did I miss?

I'm not sure that I would write the best FAQ on the subject: although I 
could write up the Python community consensus, I don't agree with it 
fully because I think the advocates of static typing make good points. I 
think optional static typing has clear benefits for safety in light of 
the alternatives.

I don't see what there is to fear in this regard either. Lisp/Dylan have 
done optional typing and range checking, and it improves safety as well 
as performance -- without changing the character of the languages or how 
they're used. I don't see why Python would be any different.

> 
>>of these combine to make Python a development environment that 
>>encourages functional programming _and all development should be done 
>>this way_. [...]
> 
> 
> (I don't think "functional programming" means what you think it
> means.  Functional programming is programming without
> side-effects.)
> 
Actually, yes, this is what I mean. The multiple variable assignment and 
multiple return values in Python allows for programming without 
side-effects. In addition, I think a functional programming style is the 
best style to use with command-prompt & unit testing. I think this is 
where I diverge from the mainstream on this discussion, because I'm 
influenced by my Lisp experience.

Brandon