Yet Another PEP: Query Protocol Interface or __query__

[Clark C. Evans]

On Wed, 21 Mar 2001, Delaney, Timothy wrote:
> So far as I can see, this PEP does not solve one basic 
> problem - interfaces which the class writer doesn't know about.

I think that this is a problem it does not set out to solve,
Alex Martelli's last post gave some insightful ways this
can be done.   Something like this can go into another PEP.
As this PEP doesn't prevent such a mechanism.

> I think it would be better if an interface was actually a class instance
> which specified exactly what it required. This could not only be methods (or
> other attributes), but also the (minimum) parameters required (and possibly
> their types) and even any pre- or post- conditions required by the
> interface. It could also mark "optional" features which if available
> will be used.

Right.  This is a complicated issue, and this PEP doesn't 
attempt to solve this.  It only attempts to introduce a 
simple mechanism to allow "declarations" in such a way
so that "discovery" can be added later.

> This instance then gets passed to the __query__() method. The __query__()
> method then inspects the requirements, and returns either a class instance
> or None. The class instance could either be self or a proxy to self or
> something completely separate. A None of course means that it cannot meet
> the requirements for the interface.

I like returning None!  You are I think the third person to 
suggest this, so I'll update the PEP with this suggestion.

> If no __query__() method is defined on the class, the query() function would
> then inspect the methods and other attributes of the class to determine if
> it meets the requirements of the interface. Naturally, interfaces with
> post-conditions would have to fail immediately in this case, and any
> pre-conditions which could not be readily determined would also have to fail
> the interface test immediately. A "readily-determined" pre-condition would
> be something like "attribute x == 3" (not a good example, but a simple one).
> 
> This seems to me a much more general and useful way of specifying
> interfaces, whilst covering all the things an interface may need. It allows
> the __query__() method to return different things on different invocations
> for the same interface, depending on the state of the class. For example, a
> file-like object may be unable to meet the "file-like" interface until it
> has all its data in memory. Until this is the case, it would return None
> from its __query__() method for an interface which required the read()
> method.

Right.  All this is good, and I'm specifically not trying to 
prevent this kind of stuff.  I just wanted a simple way to 
get at interfaces that are declared _without_ diving into
this type of stuff... 

> I may well just try implementing this some time ... most of it shouldn't be
> too hard. Unfortunately, I've got a nasty deadline coming up ... :(

Kewl.

Thank you so much for the feedback!

Clark