[Python-ideas] Is there a good reason to use * for multiplication?

[Steven D'Aprano]

On 14/10/12 02:22, Mike Meyer wrote:
> On Sat, 13 Oct 2012 19:18:12 +1100
> Steven D'Aprano<steve at pearwood.info>  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