Static typing

[Scott David Daniels]

Bruno Desthuilliers wrote:
> Michael Muller wrote:
>> Is there currently any plan to introduce static typing in any future
>> version of Python?  
> Seriously, why would you do that ?

You _might_ want some static typing information as program
documentation or to enable efficient program translation.  The
types sig was interested in allowing type annotation where
possible.  Remember, the type you might want may be more like
"what protocol must these objects (the ones passing through
this variable) follow" than "what are the construction details
of these objects".

I would like to see interface descriptions describing what
kinds of parameters are required and results produced for
packages that I am considering using.  If there were a single
central-python-endorsed form for those descriptions even better.
If the descriptions can be mechanically read, and at least
sometimes mechincally checked (possibly slowly, possibly only
for slow execution), I might use such a system to check a module
before announcing it to the world.

A very old Sun study determined that most variables in a
dynamically typed system (smalltalk, IIRC) are almost always
of the same type.

David Ungar got a fair amount of mileage out of optimizing for
a guessed common case in a protype-driven language where you
couldn't even name types in the language (you make objects
"just like that one except...").

I had a sketch of how to optimize for OODBs using behavior-based
typing.  The big trick was to use the DB's knowledge of the classes
in the DB (provided for each instance in the DB) to determine
when there was, at least currently, only one method for the given
function.  An environment like that might be able to do much
better at query optimization than any OODB that allows you to
store arbitrary objects and retrieve them based on message calls.

-Scott David Daniels
Scott.Daniels at Acm.Org