[Python-Dev] Sneaky 'super' instances

[Phillip J. Eby]

At 04:52 PM 6/10/03 -0700, Brett C. wrote:
>Bug 729103 discovered an interesting little issue; 'super' instances cause 
>inspect.isroutine to return True since it also poses as a non-data 
>descriptor.  Now this is bad because pydoc then tries to get a __name__ 
>attribute out of it which it lacks because it is an instance of a class 
>and not really a function or method.
>
>So, should I change inspect.isroutine to check to see if its argument is 
>an instance of 'super'?  Is there a robust way to check if something is an 
>instance of a class which could be used instead to make this more general 
>(like lacking a __name__ attribute)?  Or do we just cause pydoc to spit 
>out "RTM online" every time it raises an error.  =)

IMO, inspect and pydoc are hopelessly broken in the post-2.2 world, in that 
they are built on pre-unification assumptions.  This example is just the 
tip of a very nasty iceberg.

I realize I'm not answering your question; I'm just taking the opportunity 
to bring back up something that Guido and I briefly discussed a couple 
months ago:

http://peak.telecommunity.com/protocol_ref/protocols-example1.html

If we had a framework such as the one described, and we realized we wanted 
super instances documented, we'd only need to decide how we'd like them to 
be documented, instead of trying to figure out what tangled web of 
assumptions pydoc and inspect (or other tools, for that matter) make about 
various kinds of objects.

I hope to have some cycles soon to work on such a framework, but since it 
effectively depends on both PEP 246 and an unwritten PEP for a "protocol 
declaration API" like the one in PyProtocols, it would be good to get some 
idea of whether the Python developer community feels this is a good 
direction for me to pursue.  In particular, it would be useful to have some 
feedback on whether PyProtocols looks PEP-worthy (for 2.4 stdlib, I 
presume).  If so, then it's also reasonable for me to target a 
documentation framework for that timeframe.  (Specifically, a set of 
interface definitions and adapters for Python built-ins, with a few simple 
output tools.)