[PEAK] Debugging code that uses PyProtocols

[Bob Ippolito]

On Feb 19, 2004, at 10:42 PM, Phillip J. Eby wrote:

> At 09:28 PM 2/19/04 -0500, Bob Ippolito wrote:
>> I was wondering.. it can often be time consuming to track down a 
>> problem if you forget to implement a protocol, are missing an 
>> adapter, etc.  Are there any introspection facilities for PyProtocols 
>> for debugging purposes... such as "what protocols does this object 
>> directly support", "what is the adapter path from protocol A to 
>> protocol B", etc.
>>
>> It would be great to add this kind of facility to an IDE or 
>> something.. make graphviz output, etc.
>
> I deliberately avoided providing this type of introspection because 
> it's an attractive nuisance.  A lot of what I consider mis-design in 
> Zope is based on introspecting things that are not anybody's business 
> but the object involved.  So, one of my goals for PyProtocols was to 
> emphatically demonstrate that interface introspection is almost never 
> necessary, and that designs that don't rely on it are more flexible 
> and robust.
>
> I did, however, leave hooks for persons with an appropriate level of 
> motivation to add introspection capabilities to their *own* objects.  
> For example, if you implement protocols.IOpenProvider (instances) or 
> protocols.IOpenImplementor (classes), you can receive information 
> about declarations that are made.  You can also implement 
> protocols.IImplicationListener and register to receive implication 
> declarations that occur between interfaces.
>
> You can also create a subclass of InterfaceClass, and use it as the 
> metaclass for your interfaces, adding introspection methods.  Or 
> better yet, just define an introspection interface, and declare an 
> adapter to adapt InterfaceClass to your introspection interface.
>
> So, if you want those types of facilities, they're really not that far 
> away.  I just haven't run into any use cases for them personally as 
> yet.  Even if I do, the odds are very good that I will not make them 
> part of the PyProtocols API, though.  I'll probably bury them in some 
> obscure location to avoid tempting people.  :)

That's what I figured.. I didn't actually have any intentions of using 
an introspection API from the code itself, just from the debugger to 
see what I had missed.  I still think an interface/adapter diagram 
would look cool, even if it's not useful ;)

I had a test case that wasn't working because there was no adapter path 
between two classes.. it turns out I deliberately didn't write that 
particular adapter because it was not possible to satisfy the entire 
target interface in the general case.  The adapter path for that test 
case existed in a previous version of ptypes because it used to infer 
that some arrays and structures are fixed length, where the current 
version treats every array and structure as variable length.  I removed 
all non-essential code before porting to PyProtocols so I could get it 
working with less hassle.  That said, I did end up adding an adapter as 
a temporary measure that makes the test case pass, but it explicitly 
declares that it does not support the "I know my own size" part of the 
interface.

-bob