[Interface-dev] Re: Class -> interface adapters, and design question

[Steve Alexander]

Jim wrote:
 >
> I have been considering treating tuples specially in the adapter service.
> We have a concept of multi-adapters, which is quite powerful.  I've
> been thinking of making a single-adapter operation on a tuple imply
> multi-adaptation. If we did this, then:
> 
>    IBar((x, y))
> 
> would look up a multi-adapter to IBar.

How about IBar.multiadapt(x, y),
and IBar.multiadapt(x, y, default='Bob') ?

I used 'default' instead of 'alternate' because as a speaker of British 
English, I don't use 'alternate' in this way.  I use 'alternative'.  For 
me, 'alternate' is a verb only.


> Further,
> 
>    IBar((x, ))
> 
> would also look up a multi-adapter, which would be the same as looking up
> a single adapter in this case except that the __conform__ check would fail
> (and, as an optimization, we could mnage to bypass it altogether), as would
> the check for whether the objects (a tuple) already provides IBar.

Understanding all that relies on knowing about the internals of PEP 246 
vs multi-adapters.  I don't think users of interfaces and adapters 
should have to know about these things.


> This is very appealing to me, but it would fail if we started declaring interfaces
> for or adapting tuple. This has kept me from doing it so far, but it might be worth
> saying yagni (for adapting tuple).

I'd like to be able to present a tuple.  I guess that still works 
though, as presentation uses multi-adapters.

I think having different behaviour for tuples will lead to bugs in 
application code like we get now with string substitution.

   raise TypeError('The value %r was not a Foo or a Bar' % value)

This is fine if the value is nether a Foo nor a Bar nor a tuple.  It is 
confusing if the value is a 1-tuple, and will fail otherwise.

However, for aesthetic reasons, I dislike this:

   raise TypeError('The value %r was not a Foo or a Bar' % (value, ))


-- 
Steve Alexander