does lack of type declarations make Python unsafe?

W Isaac Carroll icarroll at pobox.com
Wed Jun 18 15:49:39 EDT 2003


Alex Martelli wrote:
>David Abrahams wrote:
>>Alex Martelli wrote:
>>>But this has little to do with the need of 'type declarations'.  I
>>>suspect that a statically typed language would also be better off
>>>without them, relying on type inferencing instead, a la Haskell (and
>>>Haskell's typeclasses to keep the inferencing as wide as feasible),
>>>for example.  But I have no research to back this up;-).
>>
>>I don't have any first-hand experience, but the experience of friends
>>of mine who have used Haskell is that it can be exceedingly difficult
>>to locate the source of a type error when it does occur, since the
>>inference engine may propagate the "wrong" type back much further than
>>the source of the error.
> 
> Surely the compiler should easily be able to annotate the sources with
> the information it has inferred, including, in particular, type information.
> Thus it cannot possibly be any harder to identify the error point than
> if the same type declarations had been laboriously, redundantly written
> out by hand -- except, at worst, for a slight omission in the tool of a
> feature which would be easily provided.

My understanding is that the error reporting problem arises from the 
type inferencer assuming that everything it has seen so far is correct, 
and the first inconsistency it finds is the error it should report. For 
example, if Python had inferred static types then compiling

     def f(x):
         if x == 0:
             return False   # error actually here
         elif x == 1:
             return "one"   # error reported here
         elif x == 2:
             return "two"
         elif x == 3:
             return "three"

would report that "one" was not a boolean even though it is more likely 
that False was the actual error. This paper 
(http://citeseer.nj.nec.com/heeren02improving.html) shows how the error 
messages can be improved by using a (slower and more complex) constraint 
graph rather than the traditional (bad error message generating) 
unification method.

TTFN






More information about the Python-list mailing list