On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen <ro...@uw.edu> wrote: > In article <c9841b1f-80f3-4e77-83e6-f71859524...@langa.pl>, > Łukasz Langa <luk...@langa.pl> wrote: > >> Hello, >> Since the initial version, several minor changes have been made to the >> PEP. The history is visible on hg.python.org. The most important >> change in this version is that I introduced ABC support and completed >> a reference implementation. >> >> No open issues remain from my point of view. > > Is it true that this cannot be used for instance and class methods? It > dispatches based on the first argument, which is "self" for instance > methods, whereas the second argument would almost certainly be the > argument one would want to use for conditional dispatch.
Correct. OO and generic functions are different development paradigms, and there are limitations on mixing them. Generic functions are for stateless algorithms, which expect to receive all required input through their arguments. By contrast, class and instance methods expect to receive some state implicitly - in many respects, they *already are* generic functions. Thus, this is really a request for dual dispatch in disguise: you want to first dispatch on the class or instance (through method dispatch) and *then* dispatch on the second argument (through generic function dispatch). Dual dispatch is much harder than single dispatch and "functools.singledispatch" does not and should not support it (it's in the name). As PJE noted, you *can* use singledispatch with staticmethods, as that eliminates the dual dispatch behaviour by removing the class and instance based dispatch step. You can also register already bound class and instance methods as implementations for a generic function, as that also resolves the dual dispatch in a way that means the single dispatch implementation doesn't even need to be aware it is happening. I expect we will see improved tools for integrating class based dispatch and generic function dispatch in the future, but we should *not* try to engineer a solution up front. Doing so would involve too much guessing about possible use cases, rather than letting the design be informed by the *actual* use cases that emerge in practice. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
