[IPython-dev] Extensions/pydb_ipy.py added

R. Bernstein rocky at panix.com
Sat Oct 28 10:47:14 CDT 2006


Ville M. Vainio writes:
 > On 10/28/06, R. Bernstein <rocky at panix.com> wrote:
 > 
 > > But one other thing regarding call_pydb(). And I'm not really sure how
 > > to fix. So if anyone has suggestions...
 > >
 > > pydb.runv() should be using the ipython Pdb class which has pdef, pdoc
 > > commands added and not the pydb one.
 > 
 > Would it make sense to import pydb.pydb module in pydb_ipy.py, and
 > inject the ipython version of Pdb class to the pydb module namespace?
 > That way main() would instantiate the ipython version...

Good idea! That's be great!

By the way this brings up something else that's been puzzling me:
changing the prompt (Pdb) versus ipdb>. Here's the concern.  If you
are running say from emacs (or something else that is watching output)
the regexp looks for those prompts. The more variation we have, the
more variation we need in those kinds of front-ends. Already I
experienced confusion in those when the wrong regexps are used.  Also,
already there is too much complexity in the regexps.

I'm a culprit of prompt proliferation myself. But here's my rational.
I've changed the prompt from (Pdb) to (Pydb) because the command set
and way things get output (e.g. breakpoint listings, call stack
listings) is already sufficiently different that I think this cue is
needed to help folks keep in mind which command set to use. And such
front-end would need to know too for the same reason.

But I'm not sure the same could be said for the distinction say of
being in a post-mortem called from ipython, Python, or a shell.  One
would know the distinction between which is which because of the way
the output is shown. So is it really necessary to *also* change the
prompt?

 > 
 > 
 > >  > Ok; though does the existence of *list syntax not make pydb.runv()
 > >  > slightly redundant?
 > >
 > > Well, in the os module there is:
 > >   execl(            path, arg0, arg1, ...)
 > >   execle(           path, arg0, arg1, ..., env)
 > >   execlp(           file, arg0, arg1, ...)
 > >   execlpe(    file, arg0, arg1, ..., env)
 > >   execv(            path, args)
 > >   execve(           path, args, env)
 > >   execvp(           file, args)
 > >   execvpe(    file, args, env)
 > >
 > >   spawnl(             mode, path, ...)
 > >   spawnle(      mode, path, ..., env)
 > >   spawnlp(      mode, file, ...)
 > >   spawnlpe(     mode, file, ..., env)
 > >   spawnv(             mode, path, args)
 > >   spawnve(      mode, path, args, env)
 > >   spawnvp(      mode, file, args)
 > >   spawnvpe(     mode, file, args, env)
 > >
 > > The "run" suffixes were drawn from this (which in turn are drawn from
 > > the C library system calls.)
 > 
 > Those functions were introduced long before *arglist syntax (on caller
 > side)... I'm not sure whether anyone actualle "likes" those functions
 > anymore. 

Maybe - I don't know. The *arglist syntax is a been around for a
number of years, and I'll bet you'll find lots of code that was
written/modified after it was around that uses "v" forms. Can you
point me to some discussion on this, like a PEP which substantiates
this claim?

I think of this as sort of in that category of things in ipython where
some places 1/0 is used for True/False. If you want to make it your
style to not use the "v" forms, sure, okay. Personally, I like to
reduce complexity and increase clarity. The v forms which also appear
as a prefix in the C libraries "v*print*", have probably a longer
history than the l suffix forms.


More information about the IPython-dev mailing list