Adding static typing to Python

[Alexander Jerusalem]

"Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> wrote in message news:<mailman.1014210154.9297.python-list at python.org>...
> ----- Original Message -----
> From: "Alexander Jerusalem" <ajeru at vknn.org>
> 
> 
> > That's obviously not the opinion of the members of the "The Python
> > type system SIG" including Guido van Rossum, otherwise they wouldn't
> > consider adding static types as an optional feature.
> >
> > Alexander
> >
> >
> > Daniel Klein <danielk at aracnet.com> wrote in message
>  news:<55367u4imqamlmv8ou707t40dk1jolrkmc at 4ax.com>...
> > > The point is that it ceases to be the same language with the same
>  attractions
> > > (or flaws) depending on how you look at it.
> > >
> > > Dan
> 
> Static types as an optional feature for function/method interfaces is
> not a bad thing, and does not really change the language; but the key
> word here is "optional." 

My suggestion for adding static typing included this word "optional"
from the very beginning. I'm not seriously suggesting that everyone
reengineer their code to include static typing and I see many benefits
in dynamic typing as well.

> If static typing of function arguments is
> optional, I for one am not likely to use it, so the language hasn't
> changed.

Exactly, that's what I said from the beginning.

> 
> Static typing is used by compilers to improve performance, I'm told;
> but to do it with an interpreter would require implicit typechecking
> by the interpreter core.  This would probably be faster than explicit
> typechecking (as in, write it yourself) but I can't help but see it as
> a performance loss vs. the usual method (no typechecks at all,
> exceptions thrown for interface mismatches).

The proposals of the types-SIG say that static typing is used on a per
module basis. That means that weather there is or is not a performance
improvement it's only going to affect you if you choose to use the
static types.

Alexander