Re: python.el fixes for Emacs 22

[Ken Manheimer]

On Feb 19, 2008 7:30 PM, Nick Roberts <address@hidden> wrote:

>  >     in any case, i *do* want to see pdb tracking included in whichever.
>  >     as the author of the feature, i should be able to authorize its use
>  >     wherever, and am frustrated with the twisty turns of events that have
>  >     prevented that.
>  >
>  > If you wrote the original version, we can install that
>  > with papers from you alone.  (Just say that you consider
>  > it a change to Emacs and your assignment will cover it.)
>  [...]
> As Ken is the author of these changes, has an assignment for Emacs and is keen
> to see them installed, to move things along I have installed them.

yay!  thanks!

> My understanding is that the advantage of Pdbtrack is that you can start to
> debug on the fly.  There's a small example attached below using a file called
> fibo.py (which I probably pinched from somewhere, but I can't remember where).
> However, as I've said before I'm not a Python programmer and Ken can probably
> explain better.

the crucial thing is that, with an interactive language, you're much
more able, and more likely, to trigger debugging whenever you need to
do so.  the idea of having to switch to a special debugging
environment (like gdb/gud) is a holdover from dealing with compiled
code, and means you have to restart your program and resurrect the
context where the problem happened.  that often is a terrible hassle
and loss of context.  (imagine if you had to restart emacs to debug
elisp.  pdb tracking is the minimalist equivalent of edebug.)

instead, pdb tracking makes debugger sensitivity available at every moment.

the way you've implemented it, you put the comint hook only in the
python-shell.  the thing is, python programs aren't only run from
python-shell.  in fact, many python programs and servers are usually
launched as regular commands, from bash shells.  in python-mode.el,
pdb tracking is hooked into all comint shells, and i would like to see
that same thing in the python.el version.

the way i most commonly  use it, nowadays, is with python-based
servers, like zope, which i launch as bash shell commands in
non-forking "development" mode.  the server runs normally  until i
arrange for a pdb.set_trace() to be hit, or i have it rigged to go to
pdb for uncaught exceptions.  in many cases i can edit code to add the
set_trace() on the fly, in the filesystem or in application-resident
storage.  the debugging traces show up in the shell where i launched
the server, and pdb tracking kicks in.

there's a provision, not yet ported to the python.el version, which
handles the case where the traced script doesn't actually live in the
local filesystem.  in this case, when pdb tracking is unable to find
the script according to indicated path, it looks for a python-mode
buffer with the same file name as the target, and uses that.  this is
a very general approach that works with stored or remote procedures in
any application, not just zope.

there's one further, much smaller tweak to add.  more recent versions
of python-mode (than the one you evidently were using) provide for
recursive debugging, where you can delve into an arbitrary statement
in the midst of debugging something else, and return to where you
started.  the regular expressions need to be adjusted to account for
that situation

(i have wanted to mention this approach to instrumenting emacs as a
debugging environment for a long time, particularly at times when
rejiggering of gud was being discussed.  pdb tracking features are
pretty minimal - it's just maintenance of the arrow overlay in the
target file, as you step through - but the original implementation was
just 150 lines of code, and over half of those were comments.  gud
does a lot more - but it's many orders of magnitude larger.  i think
this more loosely coupled approach may be a lot more useful and
efficient particularly for interpreted languages.)

> Note that python-shell is similar to run-python and one should probably
> eventually subsume the other.
>
> So, all credit to Ken, complaints to me... no, what the heck, give Ken your
> grief too!
>
> More seriously, this is only on the trunk and I can always revert these 
> changes
> if there are problems.
>
> Enjoy!
>
> Ken,
>
> Have you got write access yet?

yes.

i'm hoping to have time to work on this more, hopefully tomorrow or
friday.  i'd like to put in all the features i've described (though i
certainly wouldn't mind someone else beating me to it, if anyone is so
inclined), and check them in to the trunk.  let me know if you there
are any objections.

also, i've also been talking with barry and skip, who would also be
interested in seeing the python mode versions converge.  i do see that
python-mode.el is actively maintained - it's current with the
pre-release python 3.0, and it looks like a much more complete
language mode than python.el.  would there be interest in helping to
get this convergence?  is python.el actively maintained, and if so,
would the maintainers be interested in helping consolidate the
versions?

ken

> --
> Nick                                           http://www.inet.net.nz/~nickrob
> ---------------------------------------
>
> # Fibonacci numbers module (fibo.py)
>
> def fib (n):    # write Fibonacci series up to n
>    a, b = 0, 1
>    while b < n:
>        print b,
>        a, b = b, a+b
>
> def fib2 (n): # return Fibonacci series up to n
>    result = []
>    a, b = 0, 1
>    while b < n:
>        result.append (b)
>        a, b = b, a+b
>    return result
>
> ---------------------------------------
>
> Pdbtrack:
>
> M-x python-shell (note doesn't use run-python)
>
> Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25)
> [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import pdb
> >>> import fibo
> >>> pdb.run ("fibo.fib(1000)")
> > <string>(1)<module>()
> (Pdb) b fibo.py:5
> Breakpoint 1 at /home/nickrob/python/fibo.py:5
> (Pdb) c
> > /home/nickrob/python/fibo.py(5)fib()
> -> while b < n:
> (Pdb)
>
> Source should appear in buffer with overlay arrow.
>



-- 
ken
http://myriadicity.net