[Types-sig] Why I don't like static types in Python

[Justus Pendleton]

On Thu, Nov 26, 1998 at 07:07:20PM +0100, Vladimir Marangozov wrote:
> It's quite unclear to me, even after the 50 types-sig messages that landed
> in my inbox, what an (optional) Python interface is, and why should I feel
> happier if the Scarecrow (or another) formula is implemented in some way

I must say that I am in much the same state.  I haven't really seen anyone
try to explain why I should feel happier if static types and interfaces are
implemented in Python.  Maybe if someone could give me an example of a real
world problem they couldn't solve in Python because it lacked these features
it would be easier for me to understand the need we are trying to address
here.

Having read through Roger Masse's original paper on "Add Later" types as well
as the various follow ups it seems that the reasons to use static types are:

1.  Static types can improve readability by making the programmer's
    intentions more explicit,
2.  Optimize for increased performance,
3.  For detecting type errors,
4.  The existing type system in Python is nice for development within small
    groups but is not well suited for large-scale development because of the
    difficulty in specifying a common interface without implementation to
    convey behavior.

All in all, those are, in my opinion, thoroughly unconvincing arguments.

[Caveat: I am neither a language nor a compiler designer and don't know a
whole lot about either so I may be talking out of my ass on all of this.  If
I am, I'm sure someone will let me know :-)  ]

-------------------------------------------------------------------------
1.  I don't think that static types really improve readability in any way
whatsoever.  The problem?  The type is only shown when the variable is
declared, not every time it is used.  Even though C is statically typed lots
of people use Hungarian notation to get around this very problem.  If we are
really interested in increasing the readability of programs by making the
programmer's intentions more explicit then why don't we develop a Dutch
naming scheme and use that (i.e. port_h [h => heel]) instead?

-------------------------------------------------------------------------
2.  I agree with Skip Montinaro's comments that it's not clear we've come
close to exhausting the performance possibilities of Python as it currently
exists.  He and others have pointed out other interesting avenues to explore.
If performance is the concern then I think rather than changing the syntax in
any way we should first try to make nonvisible changes.  Maybe there could be
some kind of JIT compiler for Python, I dunno.  Would it be possible for
there to be a Python compiler that does global analysis of the entire program
and then does some magic type inferencing and dynamic code recompilation to
notice that var is only ever assigned integers and then generate appropriate
byte code for that situation?

What's more, I'm not convinced that performance is such an issue.  I'm
sure that other people have had other experiences, but at my work the only
times that speed has ever mattered it has mattered so much that Python could
never possibly be a contender no matter how fast it is.  When Python is
playing the role of a glue or an extension language, it's already fast enough
for every use I've ever seen.  On the other hand, even if we do nothing
Python will be twice as fast next year as it is this year.  How fast is fast
enough?  How slow is too slow?  

More to the point, how much will static typing in Python actually affect
these things?  Would we be willing to add a change as major as static typing
for a 10% speed increase?

-------------------------------------------------------------------------
3.  Roger Masse writes that static typing provides an 'improved level of type
safety and program correctness' but I'm not aware of any empirical evidence
of this.  Is this just simply "common sense"?  I am wary of "common sense"
that is lacking an empirical foundation.  Don't forget that for many people
it was "common sense" that the earth was flat, that the earth was the center
of the universe, and that maggots spontaneously generated from rotten meat.
Why should we rush to change our favorite language when their is no proof
that doing so will provide the benefits we claim we want?

Is a strongly typed system actually safer in any way whatsoever?  As Dave
Beazley asks, "are there really huge numbers of people out there writing
unreliable Python programs? Is type-safety going to solve their problem even
if it were available?"  Why add a language feature that doesn't solve a
problem?  C is a weakly typed language but people still seem to be able to
create "safe" systems in it....

IMHO there would be some problems with static typing in Python anyway.  Would
the static type system catch something like the following:

====================================
def myCallable( d : MyClass):
	return d.my_method()

val : MyClass
val = MyClass()
del val.my_method
myCallable(val)
====================================

Would the type system notice that I am turning val into something that no
longer conforms to the MyClass interface?

In any case, the static typing unnecessarily restricts me in this example.
The function 'myCallable' doesn't really need to have an object of MyClass
passed in.  It only needs something that has the 'my_method'.  The proposal
mentions COMPARABLE as one possible 'protocol' used in static typing.  But
what if I only implement < and >?  I would still be able to use a lot of
methods that claim to only take COMPARABLE...but the typing system would
prevent me from doing so.

Say some library designer decides that his function will only take numbers.
Now, he _thinks_ that his function only works on integers.  Actually, he's
wrong.  Because I have this nifty class that I designed that mostly works
like numbers and his function would product the right result if it were
called on my class.  But my class aren't numbers.  Maybe my class doesn't
form an abelian group under addition for whatever reason.  But that has no
effect whatsoever on the ability of this one function to Do The Right Thing
to my class.  But I can't use it because the library writer _thought_ he knew
everything about every future user of his functions.

Roger Masse asks of dynamic typing, "More importantly, how do you gain
confidence that an implementation of a file-like object has implemented seek
fully without running it?"  Just because I am using a statically typed
language I am not saved.  Sure I may have a file-like object that has a
method named seek that takes the parameters I think it's supposed to.  But
how do I know it doesn't just delete the file handle instead of actually
doing a seek?  With a statically typed language Masse's question simply
becomes,

"More importantly, how do you gain confidence that an implementation of a
file-like object has implemented seek in the way you think it ought to
implement seek without running it?"

In short, I don't think that static typing gives you a whole lot in terms of
safety...certainly not enough to warrant adding the feature to the core
language, even as an optional one.  If we had Design By Contract in Python
(with inherited assertions and so forth) would that be sufficient to satisfy
our needs for safety?  [BTW, Roger Masse writes that "static typing is a
prerequisite for design by contract" but I don't understand why.]

-------------------------------------------------------------------------
4.  I agree that specifying an interface without the implementation would be
nice for larger projects.  But couldn't that same kind of information be
generated by some documentation tool like interdoc or whatever the docutils
people have cooked up?  Shouldn't people be reading the documentation for the
code rather than the code anyway?  Why would we want to encourage people to
bypass the documentation and read the code directly?  Why would we want to
encourage skimping on documentation?  It seems that adding static typing to
Python as a way of providing documentation to Python code is somewhat
misguided.  Instead shouldn't we use __doc__ strings with structured
formatting?


-------------------------------------------------------------------------
In short my complaints about static typing (and protocols/interfaces, I
suppose) are that I don't see what problems these new features would solve
that currently available features can't.  I think there are definitely ways
that Python can improve and grow, I just don't think that static types are
one of those ways.  I look forward to hearing what proponents of static
typing and protocols think about this.

-- 
Justus Pendleton <justus@acm.org>