[IPython-dev] ipython/pydb integration - readline

R. Bernstein rocky at panix.com
Sun Oct 29 14:50:29 CST 2006


Jörgen Stenarson writes:
 > I would also like to see the ability to have separate history buffers 
 > for different modes of ipython. I find it a bit annoying to have to wade 
 > through pdb history when I'm back in standard ipython.

I believe this has been fixed by Ville in SVN and he posted something
to that effect. Again, the fix is not just for pdb, but all %run
programs. This covers the pdb-to-ipython direction I originally
mentioned. However the other direction -- ipython history bleeding
into debuggers -- has not been changed, and apparently Ville seems to
prefer this. I don't, but it's not something to I'd care to press on,
unless others feel that way. And I gather that's not the case.

 > Another thing I'd love to see is the ability to have a context sensitive 
 > tab completion. For instance when completing a magic like %run it would 
 > only complete on filenames and the command switches of %run.

Inside pydb, you will get command completion for debugger command
names. So in that sense there is some context-sensitive
completion. But inside an emacs shell (not via ipython), pydb will
also give you completion on a subcommand name (e.g. set/show/info
commands).  There's something odd in ipython's completion interface
that seems to prevent this (via ipython.el) whereas in emacs, it
doesn't.

I had a private discussion about this with Alexander Schmolck in the
context of improving the behavior in emacs and ipython.el. For each
instance of the problems uncovered, my understanding was that the
completion mechanism in ipython needs improvement first; to date
nobody has been willing to undertake fixing it.

And at present I fall in this category too - I'll be happy if some
sort of minimal pydb interaction gets into the next release; at that
point I'll reassess the effort-to-benefit ratio.

 > 
 > If this would require new functionality in the readline module 

As Ville has confirmed, the problem is not in the readline module(s)
but in ipython's completion interface. If this has been addressed at
the interface or API level in the chain-saw branch, I'd be interested
to learn of that fact.

 > we have 
 > the possibilty to experiment in pyreadline. Unfortunately at the moment 
 > pyreadline does not work under unix but for the next version I have done 
 > work to make it easier to create interfaces to different consoles. If 
 > anyone would like to pitch in and create something for unix I'm happy to 
 > include it and will help answer questions about how things work in the 
 > codebase.
 > 
 > In fact the pyreadline refactor branch is coming along nicely (I use it 
 > my self daily now). It also has some nice new features: more of the 
 > editing commands of readline have been implemented, copy paste have been 
 > improved so you can do selection of text using shift and arrow keys, a 
 > vi mode. Anyone that would like to take it for a spin can check it out 
 > from:  http://ipython.scipy.org/svn/ipython/pyreadline/branches/refactor 
 > using svn.
 > 
 > /Jörgen
 > 
 > R. Bernstein skrev:
 > > The short one sentence summary is that right now there is a single
 > > (global) readline history gets used inside %run (if not other places)
 > > and really the history from an application's %run should separate from
 > > ipython's history.
 > > 
 > > Both ipython and pydb and use readline. When pydb exits it can either
 > > write its command history, or not save it in which case it is
 > > truncated. The default is to truncate the history, and I believe the
 > > effect seen in ipython then, is that after pydb leaves the *ipython*
 > > history has artifacts of whatever the pydb setting was. That is if
 > > pydb set to truncate the history, then ipython's history is truncated;
 > > if not, then the history contains *pydb* entries in addition to the
 > > ipython entries.
 > > 
 > > Sort of. I say this because the ipython "history" command seems to
 > > work right. So does pydb's equivalent: "show commands".
 > > 
 > > There sort of is an implication that adding pydb "broke" things, but
 > > in thinking and looking at this deeper, it strikes me that the
 > > readline handling in ipython is currently a little bit broken. Just
 > > broken in a different way. And I'd be curious to learn if others have
 > > noticed this as think I have.
 > > 
 > > First, *any* program that decides to use readline that is %run from
 > > ipython (whether -d or not) will have the above issue. So as was
 > > initially observed, we have interference in the program-to-ipython
 > > side. But you also have it in the ipython-to-program side. That is,
 > > inside pdb whenever pdb prompts, *ipython* command completions are
 > > offered.  This isn't all that helpful. And as mentioned above
 > > "previous-command" (in Emacs: Ctrl-P) spans across the two, which also
 > > doesn't seem right.
 > > 
 > > I think the right solution then would be for ipython to save its
 > > history (if history saving is on), truncate the history if it can, run
 > > the command, and the reinstate the history by rereading it from the
 > > saved history file. Again, this works for all programs, not just pydb.
 > > 
 > > - - - -
 > > 
 > > One last strongly related topic which includes Fenando's comment about
 > > the necessity of Python 2.4 support. It was the following readline
 > > workaround in Debugger.py around line 68 that caused me to initially
 > > decided to punt on Python < 2.5:
 > > 
 > > 
 > >     if sys.version[:3] >= '2.5':
 > >         def __init__(self,color_scheme='NoColor',completekey=None,
 > >                      stdin=None, stdout=None):
 > >             ... # I'll come back to this below
 > >     else:
 > >         # Ugly hack: for Python 2.3-2.4, we can't call the parent constructor,
 > >         # because it binds readline and breaks tab-completion.  This means we
 > >         # have to COPY the constructor here.
 > >         def __init__(self,color_scheme='NoColor'):
 > >         ... #1
 > > 
 > > I think the intent at #1 above is basically to copy the code in pdb's
 > > __init__ constructor omitting "import readline" and the code associated
 > > with implications of that.
 > > 
 > > So it looks to me like the test on version 2.5 has more to do with
 > > testing the version of *pdb* used than anything else version 2.4 or
 > > version 2.5. Is this correct?
 > > 
 > > Assuming this is the case, when I look the 2.4 pdb versus the 2.5 pdb,
 > > I see THAT THEY BOTH IMPORT READLINE. In other words the 2.5 branch
 > > ("I'll come back to this below") should have pdb code copied minus the
 > > import readline. This has to be a separate branch still because it is
 > > different code. But none of it appears, so I'd be curious to learn why
 > > it's not needed in the 2.5 branch.
 > > 
 > > Perhaps. And perhaps not. Because if the real solution is to:
 > >  - save the command history file, 
 > >  - truncate it, 
 > >  - call "run" (or post-mortem)
 > >  - restore the history file by rereading it
 > > then perhaps the above is moot.
 > > 
 > > Comments?
 > > _______________________________________________
 > > IPython-dev mailing list
 > > IPython-dev at scipy.org
 > > http://projects.scipy.org/mailman/listinfo/ipython-dev
 > > 
 > 


More information about the IPython-dev mailing list