[Types-sig] Static typing: Towards closure?
Fri, 21 Jan 2000 06:06:53 -0500
> What is a one-line change in untyped Python may require
> an unbounded number of changes in typed Python.
> 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
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.
decade-of-its-life<wink>-ly y'rs - tim