[Python-Dev] PEP 443 - Single-dispatch generic functions (including ABC support)

[Nick Coghlan]

On Wed, May 29, 2013 at 5:41 AM, Russell E. Owen <rowen at uw.edu> wrote:
> In article <C9841B1F-80F3-4E77-83E6-F71859524BC8 at langa.pl>,
>  Łukasz Langa <lukasz at 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   |   ncoghlan at gmail.com   |   Brisbane, Australia