[Python-Dev] PEP 246: let's reset

[Phillip J. Eby]

At 09:15 AM 1/16/05 -0800, Guido van Rossum wrote:
>Given the many and various issues with automamtic adaptation
>(transitivity, lossiness, statelessness, and apparently more still)
>that might be a better approach.

Actually, I think Clark, Alex, and I are rapidly converging on a relatively 
simple common model to explain all this stuff, with only two kinds of 
adaptation covering everything we've discussed to date in a reasonable 
way.  My most recent version of my pre-PEP (not yet posted) explains the 
two kinds of adaptation in this way:

"""One type is the "extender", whose purpose is to extend the capability of 
an object or allow it to masquerade as another type of object.  An 
"extender" is not truly an object unto itself, merely a kind of "alternate 
personality" for the object it adapts.  For example, a power transformer 
might be considered an "extender" for a power outlet, because it allows the 
power to be used with different devices than it would otherwise be usable for.

By contrast, an "independent adapter" is an object that provides entirely 
different capabilities from the object it adapts, and therefore is truly an 
object in its own right.  While it only makes sense to have one extender of 
a given type for a given base object, you may have as many instances of an 
independent adapter as you like for the same base object.

For example, Python iterators are independent adapters, as are views in a 
model-view-controller framework, since each iterable may have many 
iterators in existence, each with its own independent state.  Resuming the 
previous analogy of a power outlet, you may consider independent adapters 
to be like appliances: you can plug more than one lamp into the same 
outlet, and different lamps may be on or off at a given point in 
time.  Many appliances may come and go over the lifetime of the power 
outlet -- there is no inherent connection between them because the 
appliances are independent objects rather than mere extensions of the power 
outlet."""

I then go on to propose that extenders be automatically allowed for use 
with type declaration, but that independent adapters should require 
additional red tape (e.g. an option when registering) to do so.  (An 
explicit 'adapt()' call should allow either kind of adapter, 
however.)  Meanwhile, no adapt() call should adapt an extender; it should 
instead adapt the extended object.  Clark and Alex have proposed changes to 
PEP 246 that would support these proposals within the scope of the 
'adapt()' system, and I have pre-PEPped an add-on to their system that 
allows extenders to be automatically assembled from "@like" decorators 
sprinkled over methods or extension routines.  My proposal also does away 
with the need to have a special interface type to support extender-style 
adaptation.  (I.e., it could supercede PEP 245, because interfaces can then 
simply be abstract classes or just "like" concrete classes.)