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

[Glenn Linderman]

On 5/22/2013 3:33 PM, Łukasz Langa wrote:
> 2. does not have a standard way for methods to be added to existing
>     generic functions (i.e., some are added using registration
>     functions, others require defining ``__special__`` methods, possibly
>     by monkeypatching).

I assume you are talking about things like __add__, for operator 
overloading.  And later you mention:

> To define a generic function, decorate it with the ``@singledispatch``
> decorator. Note that the dispatch happens on the type of the first
> argument, create your function accordingly:

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.

While unary operators, and one argument functions would be fully covered 
by single dispatch, it is clear that single dispatch doesn't cover a 
large collection of useful cases for operator overloading.

It would seem appropriate to me for the PEP to explain why single 
dispatch is sufficient, in the presence of a large collection of 
operations for which it has been demonstrably shown to be 
insufficient... while the solution is already in place for such 
operations, single dispatch could clearly not be used as a replacement 
solution for those operations, opening the door to the thought that 
maybe single dispatch is an insufficiently useful mechanism, and that 
perhaps at least two arguments should be used for dispatch (when they 
exist).

On the other hand, when using function call notation instead of operator 
notation, maybe single dispatch is sufficient... still, non-commutative 
operations (subtract, divide, etc.) can be difficult to express without 
resorting to function names like "backwardsSubtract" (__rsub__).  But 
even with commutative operations between unlike objects, it may be that 
only one of the objects knows how to perform the operations and must be 
the one that controls the dispatch...

Granted, there are few ternary (or n-ary) operators that are not 
expressed using functional notation anyway, but certainly there is a 
case to be made for dispatch to happen based on types of all arguments. 
While that doesn't necessarily detract from the benefits of a single 
dispatch system, it does raise the question about whether single 
dispatch is sufficient, especially in the presence of a large collection 
of (binary) operations for which it is already known to be insufficient.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130522/4f571115/attachment.html>