Re: python-mode patch

["Ken Manheimer" <ken.manheimer@gmail.com>]

On 8/20/06, Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> wrote:
> On Thu, 10 Aug 2006 16:19:58 -0400
>
> Anyway, it seems that essentially *nobody* is using python-mode from
> CVS Emacs. There are two reasons, I imagine. First, it isn't all that
> usable ATM -- there is quite a number of annoying quirks and things
> that do not work as well as they should. Most of them seem to be minor
> and not too difficult to fix, though, as the code is pretty clean.
>
> The other reason, probably even important, is that there is another
> python-mode, at http://sf.net/projects/python-mode
>
> "Our" python-mode has one important advantage, however: it uses comint
> for running Python interpreter, while the other one seems to have
> ad-hoc code for talking to the Python. Therefore I do not think it is
> a good idea to give up developing our version.

the other python-mode, python-mode.el, has one feature that i would
love (and need) to see in any python-mode before switching.  (like
others, i didn't know about the python-mode that comes with emacs 22,
and i haven't tried it.)  i originally developed it as "pdbtrack", and
barry warsaw integrated it with  python-mode.el.

what it does is add a comint-output-filter-function which looks for
the prompts from python's interactive debugger, pdb.  when it sees
them it (and if configured for it), it pops up the file containing the
function/method in the focus of the python debugger, putting an
overlay arrow on the current line.  as the user debugs in the shell
buffer, pdbtrack continues to track the current file and line,
effectively giving a screen-oriented debugging session anytime the
python debugger is run from an interactive (comint) shell.  when the
user isn't using the debugger, pdbtrack does nothing.

this has a crucial advantage over gud-style debugging for interpreted
languages - you don't need to start the program from the debugger, or
use some elaborate process connection and prepartion of the running
program to connect to a running process.  instead of telling emacs to
debug something, emacs recognized when you're debugging something and
provides suitable support.

this is not only useful when you're running interactive sessions with
the python interpreter.  it's ideal when you run any python programs,
including servers.  when i am doing development with or of Zope (a
python-based web application server), i run the server non-detached in
a shell buffer.  that way, i can dynamically add tracing to code in
the running server, or in its special scripts, and when the server
hits those traces emacs presents me with a screen-oriented debugging
session.  for just about all layers of Zope operation.   *effortless*.

the reason i mention this in such detail is because (1) it's
invaluable, (2) it was less than 150 lines of emacs lisp code,
including copious comments, docstrings, etc, (3) i think this is a
much much more promising approach than the insanely elaborate gud.el
approach - not to mention lame, for intrepreted programs, at least,
and i believe for compiled programs, as well.

150 lines of code (apparently 156, now) only gets the very basic
pdb-session file/line tracking.  you type debugging commands at the
interpreter, there are no provisions for setting breakpoints in a
screen-oriented manner, etc - but file/line tracking is 9/10 of the
value of a screen-oriented debugger, for me, and the interpreter is
quite manageable for the other 1/10.  i'd prefer if this approach were
extended to do the other stuff , but at least would like to see it
incorporated with python.el's python-mode.

if you're interested in scoping it out, look for variables and
functions that contain the string pdbtrack".  i suspect most of it can
be used exactly as is.

at 150 lines of code, and since i wrote the original, i would be happy
to sign papers for it.

> Taking it into account, I would like to become a maintainer of
> python-mode. I would also like to try and fix as much as possible (due
> to lack of my time it may not end up being all that much, though)
> before the release. It should not cause any real problems since, as I
> said, nobody appears to be using the mode currently.
>
> And it is important to have a *working* mode for the release, if it is
> to ever gain a reasonable user base.
>
> One problem I have is about naming, as it is more than a little
> confusing right now. "Our" mode is called python-mode, distributed in
> file python.el, and uses commands starting with python-. The other
> mode, originally developed by Tim Peters and maintained now (I think)
> by Barry A. Warsaw is also called python-mode.
>
> It would be good to have unambiguous way of talking about those modes.
> Does anyone have a suggestion how to avoid confusion?
>
> Would saying "GNU python-mode" make sense?
>
> --
>  Best wishes,
>    Slawomir Nowaczyk
>      ( slawomir.nowaczyk.847@student.lu.se )
>
> Never let someone who says it cannot be done interrupt the person
> who is doing it.
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>


-- 
ken
ken.manheimer@gmail.com
http://myriadicity.net