Home Original page

Typed Python?

Brett C. brett at python.org
Mon Jul 5 21:47:48 EDT 2004 
> To put it another way: Jarek complains that static typing would destroy 
> the "fun". I think he means Python's flexibility. A type inferencer 
> removes the need to declare types but a statically type-inferenced 
> language is still statically typed. It will still be strict about type 
> usage.

This is not necessarily true.  While this is how Standard ML and
friends use it, this is not how Python would use it.  Type inferencing
can be used to infer types purely for performance reasons.  In this
situation you just want to know either what possible types a variable
can be holding at any time in a block or what it's exact type is at
any point in time (time-insensitive compared to time-sensitive).

In either situation you just use the type inferencing information to
see if you can make a more direct call for the object.  Take the
LIST_APPEND opcode in 2.4, for instance.  With type inferencing, if
you knew you had exactly a list when you called 'append', you could
skip CALL_FUNCTION and all of its code (of which there is a lot) and
just call LIST_APPEND which is just PyList_Append().  Remember that
IronPython made such noise initially because its function calls were
extremely fast ... thanks to cutting out dynamicism when possible and
type inferring.

And as just a general comment, type inferencing in Python without
changing semantics is **very** limited.  My masters thesis is on
adding as much type inferencing as possible without changing any
semantics short of better argument checking at compile-time (read: you
can only type inference atomic types, which are those types with
syntactic support such as lists and dicts, in local variables since
you can inject into the global and built-in namespace and thus make it
all unknown at compile-time).  Otherwise restrictions will need to be
put into place.  Not being able to inject into the namespace of a
module would help a good amount.  That would make keeping track of
return types worth it.  Also adding support for C code that have
specific return types would help.  Lastly, type-checking of arguments
would help, but *only* if it is strict; it is no help to know
something subclasses list unless you have other restrictions to help
guarantee you know that whatever method you care about is not
overridden.

And all of this is why Starkiller and IronPython compile down to
something.  They restrict stuff by locking down what code you are
running against.  If you don't practically everything is unknown until
run-time.  So decisions would have to be made if extensive type
inferencing is added in terms of what kind of restrictions code will
have on it in order to get type inferred.

The other option after this is type feedback, which tries to
approximate what type a variable might hold.  With that you make a
guess and check it before you execute.  If your guess is right, you
take the fast code path, otherwise you fall back on the normal way. 
Trouble is that requires type information from running the program at
least once to gather run-time type information.
More information about the Python-list mailing list