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

[Tony Lownds]

> From: Tony Lownds <tony at pagedna.com>
>
> 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!
>

What do people here think?

Thanks
-Tony

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070101/bbcd1da4/attachment.html