[Python-Dev] PEP 246: let's reset (original) (raw)

Phillip J. Eby pje at telecommunity.com
Sun Jan 16 19:00:27 CET 2005

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.)

More information about the Python-Dev mailing list