[Python-Dev] PEP 443 - Single-dispatch generic functions (original) (raw)

Glenn Linderman 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 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>

More information about the Python-Dev mailing list