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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com