optional static typing for Python

Chris Mellon arkanes at gmail.com
Tue Jan 29 11:00:04 EST 2008


On Jan 28, 2008 10:31 AM, John Nagle <nagle at animats.com> wrote:
> Arnaud Delobelle wrote:
> > On Jan 27, 11:00 pm, "Russ P." <Russ.Paie... at gmail.com> wrote:
> >> On Jan 27, 2:49 pm, "André" <andre.robe... at gmail.com> wrote:
> >>> Perhaps this:http://www.python.org/dev/peps/pep-3107/mightbe
> >>> relevant?
> >>> André
> >> Thanks. If I read this correctly, this PEP is on track for Python 3.0.
> >> Wonderful!
> >
> > Note that annotations do not provide explicit typing, AFAIK:
> >
> > def f(x:int) -> int: return x*2
> >
> > is stricly equivalent to
> >
> > def f(x): return x*2
> > f.__annotations__ = {'x':int, 'return':int}
> >
> > You still need to write a type-checking wrapper.
>
>     Unenforced static typing is somewhat pointless.  If that
> goes in, it should be enforced by implementations.  Otherwise,
> maintenance programmers can't trust the type information they see.
>
>     Enforced, it makes it possible to start getting serious about
> optimizing compilers for Python, like Shed Skin.  Shed Skin
> can usually figure out typing within a module, but across module
> boundaries, some help is needed if you want to push optimization from
> run time to compile time.
>
Given the difficulty of statically analyzing Python, and the
limitations you need to add for either static typing or type inference
to be practical, I think that the real future for faster Python code
is JIT, not static optimizations. Languages which enforce static
typing are, of course, not Python - that's why they have different
names, like Pyrex or ShedSkin or RPython.

I think static Python is pretty much a waste of time, really - if I'm
going to write statically typed code using a traditional C/C++/Java
style type system, I'll use a language designed for it, like D. If I
want *real* strict typing - the kind where you can actually make a
useful inference from the fact that the program is type-correct - I'll
use Haskell or Ocaml. There is a lot of choice out there and there's
no reason to try to make Python into whatever your favorite paradigm
is.



More information about the Python-list mailing list