[Python-Dev] Sneaky 'super' instances

[Phillip J. Eby]

At 07:14 AM 6/11/03 +0200, Martin v. =?iso-8859-15?q?L=F6wis?= wrote:
>"Phillip J. Eby" <pje@telecommunity.com> writes:
>
> > 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.
>
>I'm quite skeptical about "grand new architectures" whose development
>starts off with "what we have is rubbish". In my experience, the
>rubbish that we have right now continues to be much better than what
>the grand new architecture can deliver for several years to come. So I
>would always favour evolution over revolution.
>
>That said: Feel free to attempt a revolution, but I can only be
>convinced that it is good when I see how actual code gives me actual
>pydoc-style pages in my web browser.

Fair enough.  I guess I should also clarify my "hopelessly broken" remark.

Since I work heavily with metaclasses, interfaces, and custom descriptors, 
pydoc doesn't work very well for me.  So I tend to use HappyDoc.  But 
HappyDoc doesn't handle nested classes.  (Actually, I'm not sure *any* 
current Python tool handles nested classes correctly.)  And so on.  I've 
yet to find a Python documentation tool that actually supports everything 
the language itself does.  On the scale of brokenness of the tool, 
however,  for my purposes pydoc is near the top of the list.  I've tried 
hacking on it a bit, but its assumptions run deep.  By comparison, other 
tools like epydoc required a lot less hacking to get them not to crash 
while inspecting straightforward post-2.2 constructs.  (Epydoc is also 
based on the inspect module.)  But Epydoc is more robust mainly because it 
punts by using 'repr()' when it can't figure something out.

Please note also that I wasn't trying to get anybody else to sign up to do 
the work.  I'm interested more in the availability of design feedback for 
the project; "customers", if you will.  If you're happy with pydoc and 
don't consider it broken for your purposes, then you logically and 
naturally would not be interested in improving or replacing it with 
something better.