[Python-Dev] PEP 246, redux

[Clark C. Evans]

On Wed, Jan 12, 2005 at 01:15:20PM -0800, Guido van Rossum wrote:
| [Clark]
| >   - add a flag to adapt, allowTransitive, which defaults to False
| 
| That wouldn't work very well when most adapt() calls are invoked
| implicitly through signature declarations (per my blog's proposal).

Understood.  This was a side-suggestion -- not the main thrust of my
response.  I'm writing to convince you that automatic "combined"
adaptation, even as a last resort, is a bad idea.  It should be
manual, but we can provide easy mechanisms for application developers 
to specify combined adapters easily.

On Wed, Jan 12, 2005 at 02:57:11PM -0500, Clark C. Evans wrote:
| On Wed, Jan 12, 2005 at 10:16:14AM -0800, Guido van Rossum wrote:
| | But now, since I am still in favor of automatic "combined" adaptation
| | *as a last resort*

A few problems with automatic "combined" adaptation:

  1. Handling the case of multiple adaptation pathways is one issue;
     how do you choose? There isn't a good cost algorithem since the
     goodness of an adapter depends largely on the programmer's need.

  2. Importing or commenting out the import of a module that may seem
     to have little bearing on a given chunk of code could cause
     subtle changes in behavior or adaptation errors, as a new path
     becomes available, or a previously working path is disabled.
    
  3. The technique causes people to want to say what is and isn't
     an adapter -- when this choice should be soly up to the
     appropriate developers.  I'd rather not have to standardize
     that FileName -> File is a _bad_ adaption, but File -> String
     is a good adaption.  Or whatever is in vogue that year.

  4. It's overly complicated for what it does.  I assert that this is
     a very minor use case. When transitive adaptation is needed,
     an explicit registration of an adapter can be made simple.

My current suggestion to make 'transitive adaption' easy for a 
application builder (one putting togeher components) has a few
small parts:

  - If an adaptation is not found, raise an error, but list in
    the error message two additional things: (a) what possible
    adaptation paths exist, and (b) how to register one of
    these paths in their module.
   
  - A simple method to register an adaption path, the error message
    above can even give the exact line needed,
  
       adapt.registerPath(from=A,to=C,via=B)
   
  - Make it an error to register more than one adapter from A
    to C, so that conflicts can be detected.  Also, registrations
    could be 'module specific', or local, so that adapters used 
    by a library need necessarly not be global.
    
In general, I think registries suffer all sorts of namespace and
scoping issues, which is why I had proposed __conform__ and __adapt__
Extending registry mechanism with automatic 'transitive' adapters 
makes things even worse.

Cheers,

Clark
-- 
Clark C. Evans                      Prometheus Research, LLC.
                                    http://www.prometheusresearch.com/
    o                               office: +1.203.777.2550 
  ~/ ,                              mobile: +1.203.444.0557 
 //
((   Prometheus Research: Transforming Data Into Knowledge
 \\  ,
   \/    - Research Exchange Database
   /\    - Survey & Assessment Technologies
   ` \   - Software Tools for Researchers
    ~ *