[Python-Dev] PEP 443 - Single-dispatch generic functions
v+python at g.nevcal.com
Thu May 23 02:14:55 CEST 2013
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
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...
More information about the Python-Dev