[Python-Dev] PEP 443 - Single-dispatch generic functions

[Glenn Linderman]

On 5/22/2013 5:55 PM, Guido van Rossum wrote:
> On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman <v+python at g.nevcal.com> 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.
>

Yep. The above, plus a recap of the arguments in opposition to multiple 
argument dispatch, would make the PEP stronger, which is all I was 
asking for. I sort of agree with his quote of Frederick Lundh, regarding 
the complexity of multiple argument dispatch, and multiple argument 
dispatch/overloading is one of the most complex things to understand and 
use in C++.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130522/2ef6a244/attachment.html>