Yet Another PEP: Query Protocol Interface or __query__

[Clark C. Evans]

On Wed, 21 Mar 2001, Alex Martelli wrote:
> > Please have a look at the PEP below, it is intended to be a
> > light-weight solution to "typing" based on programmer intent.
> 
> At least when read at 1 AM -- sounds cool.  Further, the
> builtin query function could support _adding interfaces to
> an object post-facto, non-invasively_, much like the
> 'typeclass'-based ideas that were floating in my mind
> recently and surfaced in some of my recent posts. 

Right.

> I.e., the query() builtin would both try getting the interface
> from the _object_, by passing that interface to the obj's
> query method, AND also try doing it the other way
> 'round -- asking the interface if it knows how to wrap
> the object so it (the interface) gets implemented. 

That is a very cool idea!  And the reverse lookup could
even be added much later as a seperate PEP.  I was trying
to stay simple and to de-couple this PEP as much as possible
from the other possibilities being tossed about in the
type special interest group.  I'd hate to have a dependency
emerge when one really isn't necessary.

> That would require interface-identifiers to be richer objects
> than just string, or a registry which associates a string
> identifying an interface with such a richer object.

I'd go for a registry, as this keeps the coupling low so
that the __query__ can be delivered without requiring 
a specific interface class to be worked out and agreed upon.
A string is good enough for many purposes... 

Of course, I love the idea of having an interface class
with the check() method as proposed by Tim Hochberg 
and refined by by Paul Prescod and Tim Peters.
This same class could also have a wrap(object) as
you suggest.  And then be linked somehow to the 
__query__ identifier.  How cool.  

You've taken this far past what I had visioned.  
I was just trying to solve a simple problem; how 
do I get an object having protocol X from an
object Y.  Right now, there is no general way
to do this and I feel adding built-in interface
getters like __iter__ is not the best long term
solution.

> Since 'interface' is so deucedly overloaded a word, maybe
> 'protocol' might be be better -- so we only get confused
> with FTP, HTTP and the like:-).

Hard one. 

Best,

Clark