[Python-Dev] Pydoc Improvements / Rewrite

Fernando Perez fperez.net at gmail.com
Sat Jan 6 02:35:25 CET 2007


Ron Adam wrote:

> Laurent Gautier wrote:

>  > From the top of my head, there might be  "ipython" (the excellent
>  > interactive console) is possibly using pydoc
>  > (in any case, I would say that the authors would be interested in
>  > developments with pydoc)

Certainly :)  I'd like to ask whether this discussion considers any kind of
merging of pydoc with epydoc.  Many projects (ipython included) are moving
towards epydoc as a more capable system than pydoc, though it would be nice
to see its API-doc-generation capabilities be part of the stdlib.  I don't
know if that's considered either too large or too orthogonal to the current
direction.

> According to the web site, ipython is based on twisted, and is currently
> still
> limited to python 2.3 and 2.4.  Also, the output of the help() function
> will not change much so I doubt it would be a problem for them.

A few corrections:

- IPython's trunk is NOT based on twisted at all, it's a self-contained
Python package which depends only on the Python standard library (plus
readline support under windows, which we also provide but requires ctypes).

- The ipython development branch does use twisted, but only for its
distributed and parallel computing capabilities.  Eventually when that
branch becomes trunk, there will /always/ be a non-twisted component for
local, terminal-based work.

- The last release (0.7.3) fully supports Python 2.5.  In fact, one nasty
bug in 2.5 with extremely slow traceback generation was kindly fixed by
python-dev in the nick of time after my pestering (an ipython user found it
first and brought it to my attention).

>  > Otherwise a quick search lead to:
>  > - "cgitb" (!? - it seems that the HTML formatting functions of pydoc
>  > are only in use - wouldn't these functions belong more naturally to
>  > "cgi" ?)
> 
> Thanks!, These html formatting functions still exist or are small enough
> to move
> into cgitb, so it will be just a matter of making sure they can be
> reached.  I don't think they will be a problem.

If anyone is interested in updating cgitb, you might want to look at
ipython's ultratb (which was born as a cgitb port to ANSI terminals):

http://projects.scipy.org/ipython/ipython/browser/ipython/trunk/IPython/ultraTB.py

It contains functionality for generating /extremely/ detailed tracebacks
with gobs of local detail.  These verbose tracebacks have let me fix many
ipython bugs from crash dumps triggered by remote code and libraries I
don't have access to, in cases where a normal traceback would have been
insufficient.  Here's a link to a slightly outdated simple example (the
formatting has improved a bit):

http://ipython.scipy.org/screenshots/snapshot1.png

Obviously the right thing to do would be to separate the ANSI coloring from
the structural formatting, so that the traceback could be formatted as
HTML, ANSI colors or anything else.  That is very much on my todo list,
since the network-enabled ipython will have browser-based interfaces in the
future.

All of ipython is BSD licensed, so any code in there is for the taking.

Best,

f



More information about the Python-Dev mailing list