[Python-3000] Adaptation vs. Generic Functions

Jim Jewett jimjjewett at gmail.com
Thu Apr 6 00:00:49 CEST 2006


> Walter Dörwald wrote:
> > What's still missing IMHO is a way for an adapter
> > to defer to the next adapter in the chain

Tim Hochberg <tim.hochberg at cox.net> wrote:
> Why not simply raise a DeferToNextAdapter exception?

It sounds good at first, but it may be overengineered.

If that means "NotImplemented", then why bother to register the
adapter?  If you're just speeding lookup, then go ahead and register
the "Next" adapter explicitly.

So I'm assuming that you really meant to support cooperative adapters.

If the adapters themselves inherit properly, that isn't a problem;
just use super.  If you really mean "whichever adapter is next, even
one I never heard about", then there is a problem with diamond
inheritance.

As Guido's blog points out, a decision between (Exact, Base) and
(Base, Exact) isn't clearcut, but can be resolved by requiring an
explicit registration for disambiguation.  nextmethod then has exactly
the same problem... Even calling all potential next methods expcitly
isn't really an answer, if some of them end up redelegating to (Base,
Base).

Or are you suggesting that each adapter function should itself be
treated as a class, with a lookup actually returning a newly created
derived class that includes each relevant adapter in its MRO?

A part of me likes that idea, but I can't help wondering if it
wouldn't make the adaptation protocols too heavyweight.


Tim Hochberg <tim.hochberg at cox.net> wrote:
> FWIW, I'm also not very enthusiastic about the
> inner try/except block that showed up at some point.

Are you worried about the implementation or the explanation?  Do you
think it would read better as

    for key in candidates:
        adapter = self.registry.get(key)
        if adapter is not None:
            return adapter(*args, **kwargs)


More information about the Python-3000 mailing list