[IPython-user] Colorizing lines in debuggers and post-mortem

R. Bernstein rocky@panix....
Sat Feb 17 22:38:50 CST 2007


Fernando Perez writes:
 > On 2/14/07, R. Bernstein <rocky@panix.com> wrote:
 > > When looking at the colorized debugger output, there something I think
 > > a little odd. IPython has a colorize routine for Python programs.  I'm
 > > referring to PyColorize.Parse.format here.  But format is not used in
 > > these listings, even though IPython also has a customized debugger
 > > "list" method.
 > >
 > > I guess the problem has to do with getting *fragments* of Python which
 > > you may get in a single line of Python code. The tokenization routine
 > > might return an error. Note though that most Python code is properly
 > > formatted when looked at on a line by line basis.
 > >
 > > I think that if the format method's interface were changed slightly,
 > > IPython could show program in debuggers and post-mortem
 > > better. Instead of format writing to the output some sort of error
 > > message when a line is malformed (or more likely incomplete), if it
 > > returned an error status or raised an exception the caller could take
 > > appropriate action.
 > >
 > > Assuming a change like this, here's how I think a listing would
 > > work. You call format on a line or range of lines, if that there's no
 > > error you accept the formatted output. Otherwise you just print the
 > > line as is (which is what is being done now).
 > 
 > Sure, I don't see a problem with that, and I'd be happy to apply such
 > a patch.  As long as you test it with things like
 > 
 > 
 > """foo.....

I had a little bit of time and played around with this. The
simple-minded solution of calling tokenize.tokenize() and reporting
back a failure, seems to work pretty well in the cases I
tried. Although I make no claim for elegance here, it's also not that
complex or that many changes either.

Below is a patch. But it is not really a proper patch for reasons
listed below. It's more intended for folks to try out to get feedback.

I think it helps; and in complicated cases where there are
continuation lines and comments, it's no worse that what's currently
there. But I'm not all that enthralled with the choice of colors. THe
reserved words for LightBG is green -- almost the same as for line
numbers. GNU emacs uses purple. And for comments GNU emacs uses brown
which I think a little better than red.

Here's why the patch isn't ideal.  First, it encorporates some of the
previous unapplied patches which are needed at least to see this via
%pydb. Since I liked this idea (aside from the color selections) and
wanted to see what go further, I also made a change to UltraTB.py.
Here I basically a copied of the same 4 or so lines added to
Debugger.py, and since I couldn't figure out how to get the current
color scheme in effect, I just hard-coded what I use: 'LightBG'.

I'm curious to hear comments from others.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Debugger-color.py
Type: application/octet-stream
Size: 5715 bytes
Desc: Changes to tokenize and colorize Python lines in %pydb
	output and UltraTB output.
Url : http://lists.ipython.scipy.org/pipermail/ipython-user/attachments/20070217/d0ed8ca4/attachment.obj 


More information about the IPython-user mailing list