(original) (raw)

On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman  wrote:  

Yet about half of the operator overloads would be incomplete if there were  
not corresponding \_\_r\*\_\_ methods (\_\_radd\_\_, \_\_rsub\_\_, etc.) because the  
second parameter is as key to the dispatch as the first.  

  
This (and your subsequent argument) sounds like a typical case of  
"perfection is the enemy of the good." Łukasz already pointed out that  
for dispatch on multiple arguments, consensus has been elusive, and  
there are some strong statements in opposition. While this does not  
exclude the possibility that it might be easier to get consensus on  
dual-argument dispatch, I think the case for dual-argument dispatch is  
still much weaker than that for single-argument dispatch.

The binary operations, which you use as the primary example, are
already special because they correspond to syntactic forms. Python
intentionally does not have a generalized syntax to invoke arbitrary
binary operations, but only supports a small number of predefined
binary operators -- code in other languages (like Haskell) that uses
"unconventional" binary operators is usually hard to read except for
mathematicians.
Since the language already offers a way to do dual-argument dispatch
for the predefined operations, your proposed dual-argument dispatch
wouldn't be particularly useful for those. (And retrofitting it would
be a very tricky business, given the many subtleties in the existing
binary operator dispatch -- for example, did you know that there's a
scenario where __radd__ is tried *before* __add__?)
For standard function calls, it would be very odd if dual-dispatch
were supported but multiple-dispatch weren't. In general, 0, 1 and
infinity are fair game for special treatment, but treating 2 special
as well usually smells. So I'd say that Łukasz's single-dispatch
proposal covers a fairly important patch of new ground, while
dual-dispatch is both much harder and less useful. Ergo, Łukasz has
made the right trade-off.