[Python-ideas] [Python-3000] PEP 3107 Function Annotations: overloadable -> (original) (raw)

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 named argument names, with a key of 'return' for the annotation of the return 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 funcannotations 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 funcannotations 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 look like a function signature. Here's Kay's original email. http://mail.python.org/pipermail/python-list/2007-January/420774.html -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).returns(str) Function(int,str)*str (Function(int,str), str) "(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,

Kay

More information about the Python-ideas mailing list