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

Glenn Linderman v+python at g.nevcal.com
Thu May 23 09:31:38 CEST 2013

On 5/23/2013 12:14 AM, Antoine Pitrou wrote:

On Thu, 23 May 2013 02:33:57 -0400 Devin Jeanpierre<jeanpierreda at gmail.com> wrote:

>On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou<solipsis at pitrou.net> wrote:

> >On Thu, 23 May 2013 12:12:26 +1000 > >Nick Coghlan<ncoghlan at gmail.com> wrote:

> >>The binary operators can be more accurately said to use a complicated > >>single-dispatch dance rather than supporting native dual-dispatch. > > > >Not one based on the type of a single argument, though. > >Why not? > >I'd expect it to look something like this: > > @singledispatch > def ladd(left, right): > return NotImplemented > > @singledispatch > def radd(right, left): > return NotImplemented > > def add(left, right): > x = ladd(left, right) > if x is not NotImplemented: > return x > x = radd(right, left) > if x is not NotImplemented: > return x > raise TypeError > >Then instead of defining add you define an overloaded >implementation of ladd, and instead of defining radd you define an >overloaded implementation of radd. Well, I don't think you can say add() dispatches based on the type of a single argument. But that may be a question of how you like to think about decomposed problems.

I suspect the point was not that add can be described as doing single dispatch (it can't), but rather that add could possibly be implemented in terms of lower-level functions doing single dispatch. If that was the point, perhaps the next level point is trying to be that single dispatch is a sufficient mechanism that can be augmented (as above) to handle more complex cases. Whether the above (which I think would need to use raise and try instead of return and if) is sufficient to handle such cases is not yet proven. The case Guido mention where radd is tried before add would seem to require a bit more complex logic than the above. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130523/5efa0e41/attachment.html>

More information about the Python-Dev mailing list