[Types-sig] optional typing and performance

[Ted Meng]

The actual format for type declaration does not matter to me
 as long as parser/compiler can recognize it. 
But I'd rather see the types declared in the doc string
since it would not change Python grammar which eases compatibility(so that
a module written for 2.0 with types could be usable for 1.5.1).

It also make experiments(adding/droping) for type proposals a lot of easier.
Since the type declarations are embedded in the doc string, the type
declarations might be added documented dynamically in FAQ 
instead of Reference manual
as performance tuning tips to efficiently use Python interpreter/compiler.

The whole point is: Python is simple, practical, yet powerful, let's
keep it that way otherwise we better switch to Java now.

 


> From poplib  Mon Nov 30 11:35:04 1998
> Date: Mon, 30 Nov 1998 17:35:11 +0100
> From: Martijn Faassen <faassen@vet.uu.nl>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: Xiangyang Ted Meng <mengx@nielsenmedia.com>
> Subject: Re: [Types-sig] optional typing and performance
> Content-Transfer-Encoding: 7bit
> X-UIDL: 822534a483a263f3c01eaa26d665c685
> 
> Xiangyang Ted Meng wrote:
> > 
> > Hi,
> > 
> > I am curious that if it was brought up before and what loop holes
> > it might have. Is it possible to embed optional type declarations
> > in the doc string, something like:
> > 
> > def function(a,b,c):
> >         '''
> >         (normal documentations)
> > 
> >         [start of python optional  types]
> > 
> >         function: int
> >         a: int, b: String, c: int
> >         d: int
> > 
> >         [end of python optional  types]
> > 
> >         '''
> > 
> >         d=a+c
> > 
> >         return d
> > 
> > It might not look good for a language designer.
> > But compared to the proposed ADD-LATER typing ( I only took
> > glimpse of the WEB posting, might have missed something)
> > like below
> > 
> > def function: int (a:int,b:String,c:int):
> > 
> >         '''
> >         (normal documentations)
> >         '''
> >         d:int =a+c
> > 
> >         return d
> 
> I agree the optional static typing proposals I've seen for Python so far
> look scary; it doesn't look much like Python, as it clutters up stuff a
> lot. Perhaps it's just that I'm not used to them yet, but I fear it
> isn't.
> 
> An alternative to using doc strings is to use a kind of old style K&R C
> style typing (was this optional too in the beginning? I suppose so!),
> mixed with some Pascallish, and docstrings:
> 
>     def function(a, b):
>         var:
>             Result: int   "The sum of a and b."  
>             a, b: int     "The things that need to be added."
>             sum: int      "Local variable used to temporarily store the
> sum."
>         """This function uses optional static type checking.
>         """
> 
>         sum = a + b
>         return sum        
>                 
> The 'var' block can safely be ignored and the program should still work.
> IDEs can even 'fold' it away, and preprocessors can rip all var blocks
> out. Docstrings can be used to document what variables are used for, so
> even this would be possible, going beyond just static typing into
> documentation:
> 
>     def function():
>         var:
>             Result "Absolutely anything can be returned"
>  
> I've used 'Result' instead of the function name, for easy copy & pasting
> of 'var' blocks. I know one shouldn't copy & paste so much it to prevent
> 'rape & paste programming', but everybody does it at times, right? var
> blocks can be copied & pasted more easily than intermixed static type
> annotations. To abstract interface, one could split the 'var' block into
> an 'signature' (or 'arg') and 'local' block, like this:
> 
>     def function(a, b):
>        signature:
>            a, b: int   "Stuff to process"
>            Result: int "Result of the entire calculation."
>        local:
>            foo, bar, baz: int "Lots of helper variables"
>        """This function does a whole lot of silly stuff to a and b.
>        """
>        
>        foo = a + b * a
>        bar = foo * 12
>        baz = foo + bar
>        return baz
> 
> Another function could share the same signature.
> 
> Python could even figure out which functions are 'fully statically
> typed', and pass them on to the Python compiler. These functions can
> still easily be prototyped in Python, and the 'signature' and 'local'
> blocks would only need to be added when the function stabilizes and we
> need the speed. A tool could automate this process, by pointing out to
> the developer which variables in a function haven't been described yet:
>    hocheck test.py
>    
>    Line 173, cannot hyperoptimize function foo; bar has no static type.
>    Line 214, cannot hyperoptimize function xyz; i, j have no static
> type.
> 
> Excercises for the reader:
> 
> * Extend this to classes
> * Make Python interfaces fit in with this scheme
> 
> Is-this-more-in-the-spirit-of-Python?-ly yours,
> 
> Martijn
>