[Python-ideas] [Python-3000] PEP 3107 Function Annotations: overloadable ->
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
> def name(argument=default:annotation) -> annotation:
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
With current syntax one ends up defining function type annotations like this
Maybe one can update PEP 8 for a recommendation, if there is just too
much syntax angst for choosing the form
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