On 14/10/12 02:22, Mike Meyer wrote:
On Sat, 13 Oct 2012 19:18:12 +1100 Steven D'Aprano
wrote: On 13/10/12 19:05, Yuval Greenfield wrote: I believe that Haskell treats operators as if they were function objects, so you could do something like:
For the record, Haskell allows operators to be used as functions by quoting them in ()'s (to provide the functionality of operator) and to turn functions into operators by quoting them in ``'s.
negative_values = map(-, values)
but I think that puts the emphasis on the wrong thing. If (and that's a big if) we did something like this, it should be a pair of methods __op__ and the right-hand version __rop__ which get called on the *operands*, not the operator/function object:
def __op__(self, other, symbol)
Yeah, but then your function has to dispatch for *all* operators. Depending on how we handle backwards compatibility with __add__ et. al.
It looks like I didn't make myself clear. I didn't think it was necessary to go into too much detail for an off-the-cuff comment about an idea that can't go anywhere for at least another five years. I should have known better :) What I meant was that standard Python operators like +, -, &, etc. would continue to dispatch at the compiler level to dunder methods __add__, __sub__, __and__ etc. But there could be a way to add new operators, in which case Python could call a dedicated dunder method __op__ with two arguments, the "other" operand and the operator itself. Your class needs to define the __op__ method, but it only needs to dispatch on operators it cares about. I have no idea how this would work out in practice, given that presumably Python would still want to raise SyntaxError on illegal/unknown operators at compile time. As I said, this is Python 4 territory. Let's sleep on it for four or six years, hey? :) -- Steven