Yet Another PEP: Query Protocol Interface or __query__

Magnus Lie Hetland mlh at idi.ntnu.no
Sun Mar 25 16:19:44 EST 2001


"Clark C. Evans" <cce at clarkevans.com> wrote in message
news:mailman.985490195.2917.python-list at python.org...
[snip]
>     This proposal puts forth a light-weight explicit mechanism
>     for the adaptation (including verification) of an object to
>     a context where a specific type, class, interface, or other
>     protocol is expected.

I like the generality here -- nice PEP overall, IMO :)

[snip]

>     To enable the first case listed in the requirements,
>     the adapt function first checks to see if the objects
>     type or the objects class are identical to the protocol.
>     If so, then the adapt function returns the object directly
>     without further ado.

Hm. So in some cases the protocol object is merely an example
(prototype) of an object satisfying the protocol, and in other
cases it represents the protocol itself (with __prodapt__ etc)?

That seems a bit ... impure to me. Maybe I've missed some
arguments pertaining to this. How about something like this:

   def adapt(obj, protocol=None, prototype=None, can_wrap=1):
       # ...

(A standard abbreviation for prototype is "proto", but I'm
afraid that could be confusing here... Perhaps "sample" could
be used? Or some other word?)

Then one could use adapt(obj,protocol) if a protocol was
available, and adapt(obj,prototype=someObject) if the protocol
was to be inferred from a prototype (i.e. the class or type).

In that case, one could perhaps use adapt(obj,SomeClass), and
the function would check if obj was an instance of SomeClass;
it would *not* check whether SomeClass and obj were instances
of the *same* class (which seems semantically weird in this
context to me...)

Oh, well. Perhaps worth 2 pennies...

>     Q:  The name __prodapt__ sucks.
>
>     A:  Suggest a better alternative; I suppose __check__ could
>         be used for the protocol side, however I dont want to
>         trample on Paul Prescods proposal.

Hm. This could, I guess, be named __adapt__ as well, except that
there is no way of marking the transitive mode :)

How about __adjust__? Sounds more transitive than __adapt__ to
me...

>From the good ol' Merriam-Webster:

> ADAPT implies a modification according to changing
> circumstances  (adapted themselves to the warmer
> climate)

And:

> ADJUST suggests bringing into a close and exact correspondence
> or harmony such as exists between parts of a mechanism
> (adjusted the budget to allow for inflation)

Hm...

*Or*, the intransitive version of __adapt__ could be
called __conform__, which is indeed intransitive. Then the
transitive version could be called __adjust__ or __adapt__ or
whatever. I think that gets my vote:

  __conform__ - method in an object which can conform to
                a protocol
  __adapt__   - method in a protocol used to adapt an
                object to it

Perhaps not perfect, but __prodapt__ **really**
sucks. <0.1 wink>

--

  Magnus Lie Hetland         http://www.hetland.org

 "Reality is that which, when you stop believing in
  it, doesn't go away."           -- Philip K. Dick






More information about the Python-list mailing list