[IPython-dev] svnversion used for Release.py
rocky at panix.com
Thu Nov 30 04:21:41 EST 2006
Fernando Perez writes:
> On 11/29/06, R. Bernstein <rocky at panix.com> wrote:
> > This helps a bit, thanks. A suitably recent version of the pydb
> > follows the Python 2.5 constructor convention - it doesn't matter what
> > the Python version is. If pydb is used, (and we do check for a
> > suitably recent version), then that hack is *not* needed. So
> > class Pdb(OldPdb):
> > """Modified Pdb class, does not load readline."""
> > if sys.version[:3] >= '2.5'
> > can become
> > if sys.version[:3] >= '2.5' or has_pydb:
> > I've attached a patch for this below.
> I think Ville already applied it, thanks.
This part yes. A couple of the others no, and I don't understand why
not. One of the patches was to remove a temporary debugging print in
IPython/Magic.py that accidentally crept in. I've included it in the
> > I'm still not clear about one other thing though, and this is not
> > addressed in the patch but perhaps should be.
> > When you create the debugger you turn off any readline completion,
> > right? But is this correct whne pydb is used? pydb sets up command
> > completion correctly for itself, and I'd venture to say that this
> > would be more helpful in the debugger context than the default ipython
> > command completion.
> IPython simply prevents pdb (the builtin one) from mucking around with
> our own completers (it would otherwise call rlcompleter and completely
> disable ipython's completions).
I'm having deja vu. This issue isn't strictly a debugger issue. Any
program that uses readline will have this, and ipython users can
invoke any such program run say via %run. So ipython needs to protect
itself in a general way.
A while back Ville noticed command history bleeding between the pydb
(or more generally the thing %run'd and ipython). So that was
addressed in a more general way than had been addressed via pdb. Well
at least from the bleeding into ipython. The bleeding in the other
direction, from ipython to the pydb (or any readline application) is
still there and Ville seems to prefer that.
As for completely disabling ipython's completions, I don't see this
happening at least with pydb and the current patch. I run an ipython
completion before issuing a %pydb or going into post-mortem. Then I
see pydb's completion inside the debugger. I leave that and I get the
same completions in ipython that I had before. However since I'm not
completely certain of the erroneous situation that was happening
before, I am not sure my test is the right one.
> It's quite possible that this
> disables pydb's completions, and in that case we should try to
> accomodate both needs: preventing pdb from breaking ipython's
> completion, while allowing pydb's completion to function.
I just checked and ipython does disable pydb's completions. In the
process, I notice that ipython doesn't allow the completion key [tab]
to be specified. Right? (If it does, I would modify the patch
> If that's not the case, patches welcome :)
Okay - here is a patch and the current outstanding patches. If there
are comments, let me know.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2507 bytes
Desc: Another round of pydb patches. Some new, some old
-------------- next part --------------
> I'll be 90% offline starting now until about Dec. 12.
> I did manage to get a patch in which I'd wanted for a long time; since
> it's debugger related, your testing and feedback would be welcome:
> now activates the interactive debugger (including pydb if available)
> AFTER an exception has fired, even if you had %pdb off. This lets you
> inspect a crashed code interactively without having to do the old
> dance '%pdb on; rerun code; %pdb off'. I like it a lot more.
Well, one thing I like a lot more about it is that it doesn't change
the debugger prompt. :-)
I've never understood the advantage of changing that. And here's why
it is unhelpful. If you are running py-shell inside Emacs or perhaps
say pick your favorite IDE that allows one to go into ipython as a
shell, then that program need to be sensitive to this change. If the
enclosing program needed to modify its behavior as a result, I could
see the distinction, but my experience has been it doesn't. Yet, in
the case of py-shell, it means even more complicated regular
Also note that recursive debug sessions are indicated by enclosing in
a set of parenthesis. So while the prompt may start off say "ipdb>" if
there is a recursive debug it would become "(ipdb>) ".
More information about the IPython-dev