PEP 3107 Function Annotations for review and comment

[Tony Lownds]

On Jan 1, 2007, at 9:48 AM, Kay Schluehr wrote:
> Good. There is still one issue. I understand that you don't want to  
> fix
> the semantics of function annotations but to be usefull some
> annotations are needed to express function types. Using those
> consistently with the notation of the enhanced function statement I
> suggest introducing an arrow expression and an __arrow__ special
> function:
>
> expr: arrow_expr ('->' arrow_expr)*
> arrow_expr: xor_expr ('|' xor_expr)*
>

I agree with the use case and I am in favor of this addition despite the
drawbacks below. While overloading __eq__ is a decent alternative,
the -> operator is so much nicer (IMO).

The precedence seems right:

Function(A) -> B | C    <=>  Function(A) -> (B | C)

Most operators special method names refer to the action or operation
rather that the symbol, eg __or__, not __vbar__. Also, since the  
token is
called RARROW, __arrow__ / __rarrow__ would be potentially easy to
mix up.

There might be opposition to adding an operator whose meaning in C
is very different. Also the operator as suggested does not have any  
meaning
on any built in objects, which is odd. We could add a meaning for  
ints/bools:

http://mathworld.wolfram.com/Implies.html

If that is reasonable I would suggest calling the special method  
__implies__
and putting the slot on PyNumberMethods. If that's just silly, I  
suggest calling
the special method __returns__.

We'll see what others say :) Thanks for the suggestion!

-Tony