Adding static typing to Python

[gbreed at cix.compulink.co.uk]

Justin Sheehy wrote:

> Python has strong typing.
> 
> It also has dynamic typing, as opposed to static typing.  This seems
> to be the thing that you're objecting to.  
> 
> Sorry to nitpick, but if you're going to talk about these sorts of
> details, getting the terminology right is a good start.

Do you have a reference for this terminology?  I haven't seen it outside 
of comp.lang.python.  The only definition I have to hand contradicts it:

<http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=strong+typing>

"Strict enforcement of type rules with no exceptions. All types are known 
at compile time, i.e. are statically bound. With variables that can store 
values of more than one type, incorrect type usage can be detected at run 
time."

Taking "static typing" literally would probably mean that an object 
couldn't change it's type after creation.  That's almost always the case 
in Python.  If you mean identifiers have to stay bound to the same type, 
it'd mean

x = 1
x *= 5L

would be illegal, because x begins as an integer and then becomes a long.  
So long as function arguments remain generic, I don't think I'd miss that 
kind of dynamic typing either.  All you have to do is rewrite it

x = 1L
x *= 5L

or forget about the int/long distinction altogether.  The arguments for 
"static typing" seem to be for explicit declarations, like

long x = 1L
x *= 5L

which is redundant -- of course x is a long.  If you want to catch 
mis-spellings, all you need is

var x = 1
x = x * 5L

and I wish you luck of it.  The proposal for adding "optional static 
typing" to Python is about typing of function arguments.  Which makes some 
sense, but if a compiler's smart enough to infer the types and point out 
where they disagree, shouldn't it also be smart enough to recognize 
patterns like

def func(arg1, arg2):
  assert isinstance(arg1, type1)
  assert isinstance(arg2, type2)

?

For optimization of libraries, you can assume the types supplied will be 
those that get supplied in your test suite.  If different types get 
supplied on deployment, default to less efficient code.

So, um, what actually is the problem?


                    Graham

         (http://www.microtonal.co.uk/)