On 5/23/2013 12:14 AM, Antoine Pitrou wrote:
On Thu, 23 May 2013 02:33:57 -0400
Devin Jeanpierre<jeanpierr...@gmail.com> wrote:
>On Thu, May 23, 2013 at 2:04 AM, Antoine Pitrou<solip...@pitrou.net> wrote:
> >On Thu, 23 May 2013 12:12:26 +1000
> >Nick Coghlan<ncogh...@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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
