[Python-Dev] PEP 443 - Single-dispatch generic functions

Nick Coghlan ncoghlan at gmail.com
Fri May 24 07:09:30 CEST 2013

On Fri, May 24, 2013 at 8:40 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> I don't think that they will. Being able to register multiple types with a
> single call reads very naturally to me, while multiple decorators still
> looks weird. Even after many years of seeing them, I still get a momentary
> "What the hell...?" moment when I see two decorators on one function. That's
> only going to be increased when both decorators are the same (apart from the
> argument). The double decorator form above looks to me as weird as:
> x = func(a)
> x = func(b)
> would. I have to stop and think about what is going on, and whether or not
> it is a mistake.

The difference is that this idiom quickly becomes familiar and unexceptional:

    def fun_floating_point(arg1, arg2):

"Oh, OK, 'fun' is a generic function, and we're registering this as
the implementation for floats and Decimals"

By contrast, the following are *always* ambiguous at the point of
definition, as it depends on how fun is defined:

    @fun.register(float, Decimal)
    def fun_floating_point(arg1, arg2):

    @fun.register([float, Decimal])
    def fun_floating_point(arg1, arg2):

Is that multiple dispatch? Or is it registering for single dispatch on
multiple different types?

Sure, we could pick the latter meaning for the standard library, but
existing generic function implementations (cited in the PEP) use the
tuple-of-types notation for multiple dispatch.

By opting for stacking decorators in the PEP and hence the stdlib, we
leave the way clear for 3rd party multi-dispatch libraries to use
multiple type arguments without introducing any ambiguity.

> So I am a strong +1 on allowing multiple types to be registered in one call.

Whereas I'm a strong -1, as the ambiguity problem it would create is
persistent and irreversible, while stacking registration decorators is
just a new idiom to become accustomed to.


More information about the Python-Dev mailing list