[Python-Dev] Sneaky 'super' instances

[Phillip J. Eby]

At 09:44 AM 6/11/03 +0100, Moore, Paul wrote:

>But in practice, I can't see anything in either of these proposals which
>really needs much change to what we currently have. I suspect that the
>reality is that they are more or less descriptions of "useful patterns"
>which can be used to offer a standard answer to issues which sometimes
>come up with current methods, but which aren't frequent or severe enough
>to justify major angst. (For example, the old one about what precisely
>constitutes a "file-like" object in a given context). In this context,
>it's not entirely clear to me why the proposals need "official sanction",
>as opposed to simply being made available as user-level libraries, with
>the possibility of migrating to "standard" status if the level of interest
>proves to justify it.

PEP 246 has a chicken-and-egg problem, because it's only useful if it's 
being used.  adapt() by itself isn't at all useful if you don't have 
components or protocols that support it.  And nobody wants to write 
components or protocols to support it, if nobody is using adapt().  If I 
understand Alex and Clark's intentions in writing the PEP, it was to get 
adapt() to have a ubiquitous presence, so that authors could assume their 
users would be able to use it.

Two years after the original PEP, I saw a way to make use of it in a 
framework I was working on, and then noticed the chicken-and-egg 
problem.  But, one thing that had changed since then was that Twisted and 
Zope both had significant "interface" packages.  I saw a way to unite them, 
using PEP 246 as a mechanism, and how to make a toolkit that would allow 
developers to use adapt() in their own programs, without having to wait for 
anybody else to adopt adapt().  I'm hoping this will end the 
chicken-and-egg problem for PEP 246, as well as increase interoperability 
between frameworks.


>As usual, I suspect the reality is somewhere between these two extremes.
>But I'd like to see the two proposals restated in the form of working
>library code. Then I could *try* them rather than arguing about theory.
>[Of course if there really *is* a need for language support, this would
>focus on the *exact* language change needed, along with a real use case
>to justify it.]

There is no need for language-level support; it's just a library.  And, 
PyProtocols, my PEP 246 implementation and extension, is available for 
download now.  As for the documentation framework sketched in the reference 
manual, that's not written.  It will be, at some point, because I need it 
for my work.  But, I'm wondering whether I should write it *such that it 
could go in the standard library*.

See, I could probably write the documentation tool faster if I used PEAK, 
my application framework.  But that would make it unlikely to ever be 
usable for the Python standard library, because that would be like 
distributing Zope in the standard library.

In effect, my question is, "Should I expend the extra effort to develop the 
documentation tool in such a way that it could easily be distributed with 
the standard library?"  And, since the tool would have to depend on 
PyProtocols, this means that (in effect) PyProtocols would have to be 
accepted for the standard library.

So, what I want to know is:

* Do other people find pydoc inadequate?

* Does it seem likely that PyProtocols would be considered as an addition 
to the standard library (and by implication, used to document the 
interfaces of "standard" Python objects)?

* Is there anything specific that anybody would want in an overhauled 
pydoc, that I should know about?

Perhaps that clarifies my position and questions a bit better.