[Python-ideas] [Python-3000] PEP 3107 Function Annotations: overloadable ->

Kay Schluehr kay.schluehr at gmx.net
Tue Jan 2 13:44:34 CET 2007

Josiah Carlson schrieb:

>Tony Lownds <tony at pagedna.com> wrote:
>>On Jan 1, 2007, at 5:39 PM, Josiah Carlson wrote:
>>>Given a reading of version 53169 of PEP 3107, I see no reason to even
>>>offer a __returns__ attribute, automatic method call, etc.  PEP 3107
>>>already defines the annotation to be specified as a dictionary of  
>>>argument names, with a key of 'return' for the annotation of the  
>>>annotation.  Is there any reason why this isn't sufficient?
>>>Even in the context of the signature PEP 362, there is no need for
>>>__returns__, as an annotation-consuming library would check the
>>>signature object for argument annotations, and the func_annotations
>>>dictionary for the 'return' key for any return annotations.
>>Something got lost in the movement between lists... __returns__ wasn't
>>going to supplant or alter func_annotations or PEP 362 in any way.
>>__returns__ was proposed as the special method attached to a new
>>operator (->). That operator could be used to write expressions that  
>>like a function signature.
>>Here's Kay's original email.
>-1 on the -> operator as specified in the email you link.  There is no
>reason to add aribtrary operators for call-site annotations.  PEP 3107
>has already defined the syntax for function definition site annotations
>as follows...
>    def name(argument=default:annotation) -> annotation:
>        body

If a function consumes or returns another function, it is quite natural 
to check against the function type ( at least for certain usefull 
annotation handlers ). Some experts call those "higher order functions". 
Programmers have found those in Pythons __builtins__ module. Others have 
guessed that decorators could be HOF. I hope this is convenient enough 
for motivation.

With current syntax one ends up defining function type annotations like this

(Function(int,str), str)

Maybe one can update PEP 8 for a recommendation, if there is just too 
much syntax angst for choosing the form

    Function(int, str)->str

where wild hordes of Pythonistas might think about this as an 
implication - and are perfectly correct about it of course, at least 
according to Curry-Howard and any person, reading at least an 
introductory paper about type theory.

The latter is also the reason why Tonys __implies__ proposal makes 
perfect sense to me.

Regards and a happy new year,


More information about the Python-ideas mailing list