On 5/22/2013 5:55 PM, Guido van Rossum wrote: > On Wed, May 22, 2013 at 5:14 PM, Glenn Linderman <v+python at g.nevcal.com> wrote: >> 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. > This (and your subsequent argument) sounds like a typical case of > "perfection is the enemy of the good." Łukasz already pointed out that > for dispatch on multiple arguments, consensus has been elusive, and > there are some strong statements in opposition. While this does not > exclude the possibility that it might be easier to get consensus on > dual-argument dispatch, I think the case for dual-argument dispatch is > still much weaker than that for single-argument dispatch. > > The binary operations, which you use as the primary example, are > already special because they correspond to syntactic forms. Python > intentionally does not have a generalized syntax to invoke arbitrary > binary operations, but only supports a small number of predefined > binary operators -- code in other languages (like Haskell) that uses > "unconventional" binary operators is usually hard to read except for > mathematicians. > > Since the language already offers a way to do dual-argument dispatch > for the predefined operations, your proposed dual-argument dispatch > wouldn't be particularly useful for those. (And retrofitting it would > be a very tricky business, given the many subtleties in the existing > binary operator dispatch -- for example, did you know that there's a > scenario where __radd__ is tried *before* __add__?) > > For standard function calls, it would be very odd if dual-dispatch > were supported but multiple-dispatch weren't. In general, 0, 1 and > infinity are fair game for special treatment, but treating 2 special > as well usually smells. So I'd say that Łukasz's single-dispatch > proposal covers a fairly important patch of new ground, while > dual-dispatch is both much harder and less useful. Ergo, Łukasz has > made the right trade-off. > Yep. The above, plus a recap of the arguments in opposition to multiple argument dispatch, would make the PEP stronger, which is all I was asking for. I sort of agree with his quote of Frederick Lundh, regarding the complexity of multiple argument dispatch, and multiple argument dispatch/overloading is one of the most complex things to understand and use in C++. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130522/2ef6a244/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4