From: Tony Lownds <[EMAIL PROTECTED]>
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
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
