[Types-sig] Static typing: Towards closure?

Richard Colley Richard.Colley@alcatel.com.au
Fri, 21 Jan 2000 18:16:52 +1100

See comments in-line...

----- Original Message -----
From: "Tim Peters" <tim_one@email.msn.com>
To: <types-sig@python.org>
Sent: Friday, 21 January 2000 10:54
Subject: RE: [Types-sig] Static typing: Towards closure?


> Where static typing costs in development time way out of proportion to its
> line count is under modification, where "all of a sudden" a conceptually
> simple change of type in one place ends up getting manually propagated all
> over the place (method X used to return Y but now returns Z, so
> all call sites need to get redeclared, as well as potentially all code
> that-- directly or indirectly -- "consumes" the return value(s)).  What is
> one-line change in untyped Python may require an unbounded number of
> in typed Python.

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

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.