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 -- http://mail.python.org/mailman/listinfo/python-list