[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 09:46 AM 1/12/05 -0800, Michael Chermside wrote:
>This is a collection of responses to various things that don't appear
>to have been resolved yet:
>
>Phillip writes:
> > if a target protocol has optional aspects, then lossy adaptation to it is
> > okay by definition.  Conversely, if the aspect is *not* optional, then
> > lossy adaptation to it is not acceptable.  I don't think there can really
> > be a middle ground; you have to decide whether the information is required
> > or not.
>
>I disagree. To belabor Alex's example, suppose LotsOfInfo has first, middle,
>and last names; PersonName has first and last, and FullName has first,
>middle initial and last. FullName's __doc__ specifically states that if
>the middle name is not available or the individual does not have a middle
>name, then "None" is acceptable.

The error, IMO, is in registering an interface-to-interface adapter from 
PersonName to FullName; at best, it should be explicitly registered only 
for concrete classes that lack some way to provide a middle name.

If you don't want to lose data implicitly, don't register an implicit 
adaptation that loses data.


>You're probably going to say "okay, then register a LotsOfInfo->FullName
>converter", and I agree. But if no such converter is registered, I
>would rather have a TypeError then an automatic conversion which produces
>incorrect results.

Then don't register a data-losing adapter for implicit adaptation for any 
possible input source; only the specific input sources that you need it for.



> > it's difficult because intuitively an interface defines a *requirement*, so
> > it seems logical to inherit from an interface in order to add requirements!
>
>Yes... I would fall into this trap as well until I'd been burned a few times.

It's burned me more than just a few times, and I *still* sometimes make it 
if I'm not paying attention.  It's just too easy to make the mistake.  So, 
I'm actually open to considering dropping interface inheritance.

For adapters, I think it's much harder to make this mistake because you 
have more time to think about whether your adapter is universal or not, and 
you can always err on the safe side.  In truth, I believe I much more 
frequently implement class-to-interface adapters than 
interface-to-interface ones.  I can always go back later and declare the 
adapter as interface-to-interface if I want, so there's no harm in starting 
them out as class-to-interface adapters.


>Gee... I'm understanding the problem a little better, but elegant
>solutions are still escaping me.

My solution is to use class-to-interface adaptation for most adaptation, 
and interface-to-interface adaptation only when the adaptation can be 
considered "correct by definition".  It seems to work for me.