Optional type declaration?

[VanL]

Hello,

Does anyone know whether optional type declaration has been considered 
for python?

An optional type declaration system for python could be implemented that 
would use either a specially formatted portion of the docstring or a new 
keyword that could specify type at compile time.  This information could 
be used to supplement documentation of a function, to optimize code at 
compile time, and to move python toward being a fully compiled as well 
as interpreted language.

Although one of python's strengths is its dynamism, that dynamism does 
not come without cost -- specifically the cost for run-time 
determination of type.  Previous postings to this newsgroup have 
highlighted this as one of the most expensive operations in python.

Run-time type evaluation can also be detrimental when the programmer 
wishes to restrict the types passed in as arguments to a function. 
While this is currently possible by importing type and then comparing 
the type of the passed-in object with a target type, this seems somewhat 
ungainly.

Rather, it would seem to me that a more 'natural' approach would be that 
taken by some other interactive/compiled languages: optional type 
declaration.  This would have several advantages:

1. Compile-time knowledge of type, with the attendant possible 
optimizations.

2. Type restriction as above, with a possibly more natural syntax.

3. No loss of dynamism or compatibility -- if no type were specified, 
run-time evaluation would still occur.

What got me thinking about this was AMK's 'grouch' tool 
<http://www.amk.ca/python/writing/mx-architecture/#SECTION000700000000000000000>, 
in which docstrings contain type information so that his ZODB maintains 
consistency.  The following is quoted from the link above:


"Grouch works by parsing sets of type declarations embedded in class 
docstrings. The declarations look like this:

class PhysicalValue (MXBase):
     """A physical value: a number (or range value) tied to a physical
     unit that automatically performs unit conversion when arithmetic
     operations are performed.

     Instance attributes:
       value : float | RangeValue
         the numeric part of the physical value
       unit : PhysicalUnit
         the unit part (may be None for inherently unitless values, in
         which case the instance just acts like a number)
     """

The type declaration language is straightforward. In the above example, 
the value attribute must be either a Python float or an instance of the 
RangeValue class, and unit must be an instance of the PhysicalUnit class."


By using variable assignments and similar type information, optionally 
included with each class and function declaration, the type of almost 
every object in a typical program could be determined by a 
recursive-descent parser, possibly opening the door for optimizations, 
including compiling python to machine code in the same fashion as lisp.

If these optimizations were possible, just including these type 
declarations in the standard library would tend to speed up many 
programs, as a lot of code is just stringing together standard library 
functions.

In addition, the docstring declarations would serve as additional 
documentation for the functions.

This is not intended to be a PEP or anything, but I wanted to raise the 
issue as I saw it, to see if it sparked any disussion.  Feel free to rip 
apart what I said to any degree.

   -V-