does lack of type declarations make Python unsafe?

[Donn Cave]

In article <bcq4c4$lff$0 at 216.39.172.122>, bokr at oz.net (Bengt Richter) 
wrote:

> On Wed, 18 Jun 2003 10:25:54 -0400, David Abrahams 
> <dave at boost-consulting.com> wrote:
>>Alex Martelli <aleax at aleax.it> writes:
>>
>>> 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.
>>
>> Furthermore, if you do everything by inference you lose the
>> explanatory power of type declarations.

Haskell style does encourage type declarations at some point, the
way I understand it.  I'm a lightweight, but my approach is usually
to write the first cut without many (or any) declarations, and add
them after I get things sorted out, just in case I have to figure
the code out later.  Or I might resort to that to help clarify a
type conflict - that out-ranks inference, of course, so it will
resolve the ambiguity that causes that ``locate the type error''
problem.  It's just a lot different when you can more or less
optionally add some type annotations, compared to a system that
forces you to declare every single thing - not only does it focus
more on the algorithm without all the declaration noise, but the
types arrived at by inference tend to be more general.

> But what does "type" really mean? ISTM that in the static typing world
> "type" mostly identifies a type of *representation* -- i.e., things that
> have compatible memory layouts. Of course any Python implementation will
> have underlying *representations* of its entities, but those are not a
> central concern of Python or Python programmers. In fact, UIAM it is a
> goal of Python design to enable programmers to forget about concrete
> representations as much as possible, except for "foreign" interfacing.
> 
> I.e., the "types" of Python are more abstract, and are more about
> abstract structure and functional compatibility than underlying
> representation. ISTM "static" typing in this world can't be a direct
> translation of the old concept, unless you are talking about an interface
> to an old-style "statically typed" world, or want to incorporate
> an encapsulated chunk of that into python.

I think I agree with your conclusion, but not at all with the rest.
Haskell's type system supports a reasonable degree of abstraction
and is certainly not about memory layout.  But Python couldn't be
statically typed without serious compromise to the language.
I guess it might be interesting to speculate about exactly what
compromises would be needed - would it be enough to just forbid any
run time change to the type (in your functional sense) of an object,
for example?  How many of the changes would also help with compilation
to native code?  But this is about design of a new language, since at
any rate it would not be compatible with the old one.

   Donn Cave, donn at u.washington.edu