[PEAK] adapt factory parameter

Phillip J. Eby pje at telecommunity.com
Wed Jun 9 19:06:01 EDT 2004

At 06:44 PM 6/9/04 -0400, Stephen Haberman wrote:

>My take on this was that by declaring two adapters for SturcturalFeature ->
>ISQLFeature, with different depths (yes, I was guessing widely on this),
>that PyProtocols would try the adapter at each depth before throwing an

Nope; only one adapter may be defined for a given "adaptation path" (see 
the PyProtocols docs).

>I've got another very similar use case where I'd like to have n
>adapters take a shot at the same type -> proto or object -> proto adaption,
>so I'd like really to see this work out.

You'd need to create some kind of union adapter, and register that along 
the appropriate path.  I'm thinking about having something like this built 
into PyProtocols eventually, but it's still a ways off.  (See 
PyProtocols/TODO.txt).  Also, the example I give below will suffice 
whenever the members of the union are statically known, which I think 
applies to your use case.  See below.

>adapters = [lambda, lambda]
>for a in adapters:
>    sqlFeature = adapt(f, ISQLFeature, factory=a)
>    if sqlFeature: return sqlFeature
>raise Exception, 'No adapter for %s' % f
>This gives each adapter a chance to see if they want to take responsibility
>for the feature and letting that feature support ISQLFeature.
>Does this look like a valid use case of the factory parameter? Basically, I
>want to try n factories/adaptors where PyProtocols only lets me try one.
>Or am I missing something that would make this easier and not require the
>use of the factory parameter?

def multi_adapter(*factories):

     def ma(ob,proto):
         for f in factories:
             result = f(ob,proto)
             if result is not None:
                 return result

     return ma


And now, you can use adapt() normally.

More information about the PEAK mailing list