[Types-sig] RFC 0.1

[Guido van Rossum]

[Greg Stein]

> Note that one benefit of associating types with names, is that you can
> shortcut the data flow analysis (so the analysis is not necessarily the
> same). But: you cannot have a name refer to different types of objects
> (which I don't like; it reduces some of Python's polymorphic and dynamic
> behavior (interfaces solve the polymorphism stuff in a typed world)).

This is a bogus argument.  From the point of view of human
readability, I find this:

   s = "the quick brown fox"
   s = string.split(s)
   del s[1]			# the fox is getting old
   s = string.join(s)

less readable and more confusing than this:

   s = "the quick brown fox"
   w = string.split(s)
   del w[1]			# the fox is getting old
   s = string.join(w)

The first version gives polymorphism a bad name; it's like a sloppy
physicist using the same symbol for velocity and accelleration.

The polymorphism that is worth having deals with function arguments
and containers and the like.  For example:

def sum(l, zero):
    s = zero
    for x in l: s = s + x
    return s

Here the type of l is sequence of <something> and the type of zero is
<something>; the only implied requirement for <something> is that
<something> + <something> returns another <something>.

The fact that this works just as well for lists of ints, floats,
strings, or even matrixes, given the appropriate zero, is valuable
polymorphism.  Other languages can only do this using parametrized
types; they get more type checking, but at a terrible cost.

Note that a type inferencer may not be able to deduce the rules I
stated above, since you could construct an example where there is no
single type <something> and yet the whole thing works.  E.g. I could
create a list [1, 2, 3, joint, "a", "b", "c"] where joint is an
instance of a class that when added to an int returns a string.
However if we had a typesystem and notation that couldn't express this
easily but that could express the stricter rules, I bet that no-one
would mind adding the stricter type declarations to the code, since
those rules most likely express the programmer's intent better.

--Guido van Rossum (home page: http://www.python.org/~guido/)