[Types-sig] Static typing: Towards closure?

Tim Peters tim_one@email.msn.com
Fri, 21 Jan 2000 06:06:53 -0500


[Tim]
> What is a one-line change in untyped Python may require
> an unbounded number of changes in typed Python.

[Richard Colley]
> That one-line change will however cause run-time grief.  If you
> returning a different type of object without modifying the
> expctations of the code that "consumes" the return value(s) then
> how can you expect a correct program.

In Python, very easily -- routinely, even.  The problem is that *people*
tend to name a most-specific type instead of the most-general type.  It's my
belief that people (including me!) explicitly declare the types of their
functions in languages like Haskell precisely because the language's
automatic inference of the most-general type leads to incomprehensible error
msgs (I never gave a thought to the most-general type, and don't recognize
what the heck it's whining about when it spits one back at me).

For a simple example, dicts and lists in Python can both be indexed by
integers, with the same thing[i] syntax, and I've very often changed a dict
to a list (or vice versa) without any code breaking as a result (a "sparse"
problem turns into a "dense" one, or vice versa).  But I'm rarely going to
think ahead clearly enough to *declare* names as "list | dict".  Indeed, for
OPT reasons I would be loathe to do so even if I were thinking ahead.  So
I'll delaying adding type info until I'm sure I've got the right choice --
and sometimes regret it later.  Running around changing decls during initial
development is simply a waste of time.

And this happens "all the time"!  I still recall one of my first Python
Snorts of Joy, after I had written a GCD algorithm for integers and realized
that the exact same code would also compute the GCD of polynomials.  Nobody
is going to see ahead clearly enough to declare such a function from the
start as having arguments and return value of type EuclidianDomain <0.1
wink>.

As a more common example, consider Python's ubiquitous but largely
undocumented use of the folklore "file-like object" protocol.  Many
functions written to work "on files" are actually much more broadly
applicable in Python, but few people are going to realize that in advance;
newbies have no chance of realizing it.

This goes on & on.  Python wasn't designed with a static view of types in
mind, and it's going to be a real strain to shove some common Python
practices into a static type system.

> What I'm trying to say, it's not going to be a one-line change
> in untyped Python.  In fact the statically typed Python has
> the advantage of automatically identifying all candidates
> for change - the untyped one requires you to guess or wait
> until runtime.

Except that, so far as correctness goes, "guessing or waiting" is often a
good bet today, and can approach certainty with increasing Python
experience.  I'll certainly use static typing for OPT, ERR and DOC *when the
code needs one of those* -- but I'm under no illusion that it's a pure win.

python-did-remarkably-well-without-any-of-this-the-first-
    decade-of-its-life<wink>-ly y'rs  - tim