Change History (29)

Some of the links to API documentation from
http://twistedmatrix.com/documents/howto/pb-usage link
to pages that return 404.
For example, the section that reads "First we look at
the server. This defines an Echoer class (derived from
pb.Root), with a method called remote_echo() ..." links
to
http://twistedmatrix.com/documents/TwistedDocs/current/api/public/twisted.spread.pb.Root.html
which is a 404.
WebCVS says that the source doc for this looks like:
<p>First we look at the server. This defines an Echoer
class (derived from
<code class="API"
base="twisted.spread">pb.Root</code>), with a method called
<code>remote_echo()</code>.
Don't know enough Twisted to say whether this is a bug
in the docs or in Lore or whether the docs are out of date.

The pb.Root link is broken because Root is actually defined
in twisted/spread/flavors.py, and is merely imported by
pb.py, so epydoc doesn't document it. Unfortunately,
typical use is to import it from pb, so the HOWTO is
correct. I'm not sure what the right fix for this is.
(This is probably a good reason to avoid nasty "promotion"
hacks where a class is defined in one module, but only
documented publicly as available from another. Yes, I'm
thinking about flow here ;)

so, you fixed the function thing already, right? then all
that's left is this "alias" thing.
Here are the ways I can think of fixing it.
* Similar to my idea (that you didn't like) about the
function problem, we could have lore do a o =
namedObject(aliasname), then *actually* like to qual(o). I
know you don't like this. :-)
* Manually maintain a list of aliases for lore to look up
all api links in and replace.
* Add more markup to allow the text of the link to be
different from the actual api link.

Yep, functions links are fixed (in CVS, anyway).
* Yep, still don't like it, especially for such a minor bug.
* Keeping an explicit list of aliases is pretty sucky, but
not as bad as your first suggestion :)
* Yuck, I don't like the idea of markup for that. What
about the print form -- epydoc can produce latex, so it
would be possible to make Lore link to API docs in print.
But if the reader sees "pb.Root (page 434)" and then turns
to 434 and finds the documentation for the flavors module,
they'll be confused.
I think what the best solution would be is to mark the alias
in the *source*. We should do this anyway; what if some
later maintainer deleted the "from flavors import Root" line
in pb.py because it wasn't needed by the code in pb.py
anymore? There should be some sign in the source that a
variable is part of the public API of a module, even if it
is just an import from elsewhere.
If we did that, then we could fix epydoc, not Lore :)
This makes sense to me, because "pb.Root" is an API, and it
should appear in the API docs...

Soo... something like, in pb.py
from twisted.python.epysupport import alias
alias('twisted.spread.flavors.Root', 'twisted.spread.pb.Root')
or maybe
alias(flavors.Root, 'twisted.spread.pb.Root')
or just
alias(flavors.Root) with a hack to look in the caller's
namespace to see which module he's coming from ;)

So, we could just "fix" this with a nasty hack: just define a trivial subclass
in pb.py, e.g.:
class Root(flavors.Root):
pass
Actually, I guess the proposed alias function could do this... but working with
epydoc rather than hacking around it is probably a better idea.

FWIW, for some reason, I don't really like the alias() plan. We are already annotating the module with its public API, by way of all. Would it be much harder to detect that instead (assuming it is all static and non-magical, of course)? I'd be happy to do some work on this, if we can get everyone to agree it's the right thing.

This is an issue for e.g. twisted.internet.stdio. It imports one of _win32stdio or _posixstdio. But those are implementation details. Docs should show up under the t.i.stdio module, somehow. (Let's leave aside that the StandardIO class doesn't currently _have_ documentation: at least the class definition should show up.)

Is there anything even approaching a consensus on how to proceed here? I'm now at a point where I think there are no real technical obstacles. The most likely approach seems to be to be defining an {{all}} in spread/pb.py, having pydoctor notice when a name from {{all}} is imported into a module and doing the appropriate magic.

Who knows what should go in pb.all ? Here's an automatically derived guess:

So, the URL that mwh points to here actually doesn't show SelectReactor as part of twisted.internet.default. Maybe it did at one point? Or maybe it's an option or something? We should generate the API docs with a recent version of pydoctor and see what they look like, because this sounds like it might already be done to me.

The URL that MWH points to here now does show SelectReactor. Hooray! I think the thing to do now is to close this ticket - our oldest open ticket! - and open a new one that deals with the specific PB documentation links issue.