Current state of python.el in the Emacs trunk

Current state of python.el in the Emacs trunk

[Christoph]

Hi,

There was a recent comment in another thread that the Python mode is 
currently poorly maintained, so I started looking into what the current 
state is and what it would take to improve it.

I noticed that the original author Dave Love has an updated version on 
his website, that, among other things, also supports Python 3. There is 
a note in the beginning of the file that this version is not covered by 
FSF copyright anymore. Can anybody (Dave?) shed some light on as to why 
there is such a big discrepancy between the Emacs version and Dave's 
version on his homepage?

Could we update the Emacs version with Dave's changes (if he agrees and 
the legal stuff is sorted out, of course)?

I would also like to volunteer to work on python.el by integrating 
Dave's changes, and work on other issues. For my own benefit, it would 
also be nice if it supported alternative implementations like 
IronPython, which right now it does not. There seems to be some support 
for Jython but just invoking the IronPython interpreter in Jython mode 
does not work and seems hokey, too.

Christoph

Current state of python.el in the Emacs trunk

[Андрей Парамонов]

In reply to Bug#7329: [Patch] Enable completion in
inferior-python-mode Dave said:

> Thanks for letting me know, but I can't do anything about problems with
> the version in Emacs.  The one I maintain has the feature, without the
> bugs people tell me about in the Emacs one.

I'm interested in better Python mode in Emacs as well.

Best wishes,
Andrey Paramonov

Re: Current state of python.el in the Emacs trunk

[Stefan Monnier]

> I noticed that the original author Dave Love has an updated version on his
> website, that, among other things, also supports Python 3. There is a note
> in the beginning of the file that this version is not covered by FSF
> copyright anymore. Can anybody (Dave?) shed some light on as to why there is
> such a big discrepancy between the Emacs version and Dave's version on
> his homepage?

AFAIK, the problem is that Dave decided to declare the new changes as
"not covered by his copyright assignment", in other words, expressly
forbidding us to use them.
I'm still not very clear if that's really what happened.

> Could we update the Emacs version with Dave's changes (if he agrees and the
> legal stuff is sorted out, of course)?

We'd be happy to do that if we could, yes.  We'd also be happy to have
Dave help maintain our python.el directly.

> I would also like to volunteer to work on python.el by integrating
> Dave's changes, and work on other issues.

If you can help clear the the communication between Dave and us, that
would be wonderful, yes.

> For my own benefit, it would also be nice if it supported alternative
> implementations like IronPython, which right now it does not.
> There seems to be some support for Jython but just invoking the
> IronPython interpreter in Jython mode does not work and seems
> hokey, too.

Patches welcome,


        Stefan

Re: Current state of python.el in the Emacs trunk

[Christoph]

On 1/27/2011 11:35 AM, Stefan Monnier wrote:

> AFAIK, the problem is that Dave decided to declare the new changes as
> "not covered by his copyright assignment", in other words, expressly
> forbidding us to use them.
> I'm still not very clear if that's really what happened.

OK. I copied him on this thread.

Dave, can you shed some light on this? I would appreciate it. Thank you!

> If you can help clear the the communication between Dave and us, that
> would be wonderful, yes.

I will try my best.

>> For my own benefit, it would also be nice if it supported alternative
>> implementations like IronPython, which right now it does not.
>
> Patches welcome,

Thanks. I will have some patches in a little while.

Christoph

Re: Current state of python.el in the Emacs trunk

[Dave Love]

[This message was stuck offline.  Apologies for the late delivery.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I noticed that the original author Dave Love has an updated version on his
>> website, that, among other things, also supports Python 3. There is a note
>> in the beginning of the file that this version is not covered by FSF
>> copyright anymore. Can anybody (Dave?) shed some light on as to why there is
>> such a big discrepancy between the Emacs version and Dave's version on
>> his homepage?

There were various ill-advised changes to the Emacs fork, for one thing,
and people weren't interested in fixing the bugs as far as I can tell,
possibly because of the propaganda from the direction of the old,
less-capable mode.

> We'd be happy to do that if we could, yes.  We'd also be happy to have
> Dave help maintain our python.el directly.

It was unrewarding even to comment on bugs in it previously, and I
wouldn't want just to help and be over-ruled in things like support for
Python 3.  In fact, much of the mode should be dumped anyway in favour
of abstraction into a general framework, as intended; I don't understand
why that was rejected.

>> I would also like to volunteer to work on python.el by integrating
>> Dave's changes, and work on other issues.
>
> If you can help clear the the communication between Dave and us, that
> would be wonderful, yes.

I responded to cyd some time ago, and I don't have time to dig that or
repeat it now, sorry.  Since you're planning to replace python.el with
python-mode.el for some strange reason, I don't understand why this is
relevant or why assignment difficulties matter, otherwise I might have
been more careful.  (python-mode.el even infringes the GPL.)

Re: Current state of python.el in the Emacs trunk

[Chong Yidong]

Dave Love <fx@gnu.org> writes:

> Since you're planning to replace python.el with python-mode.el for
> some strange reason,

This is a false statement.

Re: Current state of python.el in the Emacs trunk

[Stefan Monnier]

>> Since you're planning to replace python.el with python-mode.el for
>> some strange reason,
> This is a false statement.

Almost: there have been discussions to switch to python-mode.el
(predicated on the ability to get the copyright cleared), so Dave's
comment isn't completely false.  The only problem is that the very
reason for desiring such a switch is because nobody (including and
especially the most obvious candidate, Dave) has been willing to
maintain our python.el.
IOW it's not really that his statement is false, but that we're faced
with an inconsistent logic ;-)

Now Fabian proposes a third Python mode.  That sounds like adding insult
to injury, but I must say it is very tempting:
- its copyright is clean, like our python.el.
- he seems interested in maintaining it.
Of course, I'd rather work at bringing the various python modes closer
to each other, rather than have them fork even further, so I'm not sure
what's the best course here.


        Stefan

Re: Current state of python.el in the Emacs trunk

[Christoph]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The only problem is that the very reason for desiring such a switch is
> because nobody (including and especially the most obvious candidate,
> Dave) has been willing to maintain our python.el.

I'm confused. Didn't I offer to do maintenance work, like for example
integrating Dave's bug fixes (if he agreed to it)?

I have actually spent quite some time digging through the current
python.el mode and tried to do some clean up and fix things. For
example, the inital integration of pdbtrack a couple of years ago left a
huge amount of duplication since it was never really cleaned up. For
example: why are there two different ways to invoke a python shell?

> Now Fabian proposes a third Python mode.

I looked at it and I like it. It actually fixes some issues that the
current python.el has, especially when it comes to things like
pdbtrack. I had some issues getting some of features to work (shell
completion, for example) but that might just be because I was using
24.0.50 and/or using it wrong.

I didn't have the time to compare the current python.el with Fabian's
version as far as features go, but I didn't really miss anything while
using Fabian's new mode today.

> Of course, I'd rather work at bringing the various python modes closer
> to each other, rather than have them fork even further, so I'm not sure
> what's the best course here.

As far as python-mode.el goes...the discussion I started on this list
sparked another on the python-mode list:
http://mail.python.org/pipermail/python-mode/2011-February/000937.html

This doesn't sound like we would get on the same page anytime soon.

Christoph

Re: Current state of python.el in the Emacs trunk

[Stefan Monnier]

>> The only problem is that the very reason for desiring such a switch is
>> because nobody (including and especially the most obvious candidate,
>> Dave) has been willing to maintain our python.el.
> I'm confused. Didn't I offer to do maintenance work, like for example
> integrating Dave's bug fixes (if he agreed to it)?

Yes, you did, sorry for that.  The discussion of moving to
python-mode.el took place a good while before you suggested taking
over maintenance, so I simplified my argument by not mentioning more
recent developments.

> I have actually spent quite some time digging through the current
> python.el mode and tried to do some clean up and fix things.
> For example, the inital integration of pdbtrack a couple of years ago
> left a huge amount of duplication since it was never really cleaned
> up.  For example: why are there two different ways to invoke
> a python shell?

My best guess: historical accident.

>> Now Fabian proposes a third Python mode.
> I looked at it and I like it. It actually fixes some issues that the
> current python.el has, especially when it comes to things like
> pdbtrack. I had some issues getting some of features to work (shell
> completion, for example) but that might just be because I was using
> 24.0.50 and/or using it wrong.
> I didn't have the time to compare the current python.el with Fabian's
> version as far as features go, but I didn't really miss anything while
> using Fabian's new mode today.

Since you have a good knowledge of our current python.el, maybe you
could get together with Fabian to merge the two?

>> Of course, I'd rather work at bringing the various python modes closer
>> to each other, rather than have them fork even further, so I'm not sure
>> what's the best course here.
> As far as python-mode.el goes...the discussion I started on this list
> sparked another on the python-mode list:
> http://mail.python.org/pipermail/python-mode/2011-February/000937.html
> This doesn't sound like we would get on the same page anytime soon.

Don't trust everything you read, and don't assume every poster in
a thread is actually relevant to the problem.  AFAIK most authors of
python-mode.el would be willing to sign the needed papers and work with
us, but it's indeed likely that one or two might pose problem, and even
more likely that it'll take a lot of effort (if at all possible) to
track down all those people.
And furthermore, we don't need to integrate python-mode.el into Emacs to
bring the various python mode closer to each other.


        Stefan

Re: Current state of python.el in the Emacs trunk

[Fabian Ezequiel Gallina]

2011/2/16 Christoph <cschol2112@googlemail.com>:
> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>> Now Fabian proposes a third Python mode.

It wasn't my plan to complicate things further, it was the approach
that worked for me to solve the problem of my not-so-happy experience
with the different python modes I tried.

If it can help to enhance the current trunk's python.el status to
something better then it's good twice.

>
> I looked at it and I like it. It actually fixes some issues that the
> current python.el has, especially when it comes to things like
> pdbtrack. I had some issues getting some of features to work (shell
> completion, for example) but that might just be because I was using
> 24.0.50 and/or using it wrong.
>

That's good to hear, I fixed some shell integration and completion
stuff today, so that probably will do the trick.

> I didn't have the time to compare the current python.el with Fabian's
> version as far as features go, but I didn't really miss anything while
> using Fabian's new mode today.
>

Most of the stuff in trunk's python.el is there, so (I hope) your
feeling remains that way :)


Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com

Re: Current state of python.el in the Emacs trunk

[Dave Love]

Chong Yidong <cyd@stupidchicken.com> writes:

> Dave Love <fx@gnu.org> writes:
>
>> Since you're planning to replace python.el with python-mode.el for
>> some strange reason,
>
> This is a false statement.

I have to take statements like "The plan is to ship it with python.el
until we can ship it with python-mode.el" at face value, but I'm sorry I
forgot you previously said it was false, whether or not it is.  I should
have talked in the past tense about it, anyway.

Re: Current state of python.el in the Emacs trunk

[Dave Love]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> The only problem is that the very
> reason for desiring such a switch is because nobody (including and
> especially the most obvious candidate, Dave) has been willing to
> maintain our python.el.

I wasn't unwilling to maintain it, and I attempted in the past to get
the Emacs version fixed and prevent problems being introduced, but that
was rather unrewarding, and I gave up.  It's not appropriate anyway, as
rms seems to think I act in bad faith these days.  If I was mainatinaing
it, I'd just do what I've been doing separately, which doesn't seem
acceptable.  I haven't checked exactly what's currently in Emacs, but
I'm baffled why, for instance, it got three .py files instead of a more
maintainable one, and why changes were made which clearly broke things.

> Now Fabian proposes a third Python mode.  That sounds like adding innnsult
> to injury, but I must say it is very tempting:
> - its copyright is clean, like our python.el.
> - he seems interested in maintaining it.

I don't know what that's about, but I maintain a version with no unfixed
bugs I'm aware of, and had various features (and not misfeatures) the
others don't.  Until I started working on it at the university, it was
covered by an assignment (given potential problems with my previous
employment were disregarded) and could just have been used.  It may well
need to be fixed for the incompatible Emacs changes that get made, but
I'd fix it if told, and if it didn't break it for released versions.

> Of course, I'd rather work at bringing the various python modes closer
> to each other, rather than have them fork even further, so I'm not sure
> what's the best course here.

Why?  python.el was intentionally different from python-mode.el for
various reasons, like being a well-behaved Emacs (as opposed to XEmacs?)
mode.  I don't understand why you'd want something whose distinction as
far as I can tell is violating conventions with fewer features and extra
bugs.  Actually, after all the propaganda about it, python.el code now
seems to be migrating into python-mode.el (after stripping the copyright
headers, contrary to the licence, of course).

I do find this all pretty sad.

Re: Current state of python.el in the Emacs trunk

[Dave Love]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Don't trust everything you read, and don't assume every poster in
> a thread is actually relevant to the problem.  AFAIK most authors of
> python-mode.el would be willing to sign the needed papers and work with
> us, but it's indeed likely that one or two might pose problem, and even
> more likely that it'll take a lot of effort (if at all possible) to
> track down all those people.

I'm sure I've said this before, but when we last tried, Barry Warsaw
said he needed papers from a former employer, and couldn't get that, so
it wasn't worth pursuing any others, and it didn't look as if there was
enough information on other contributors anyway.  I may even have the
mail somewhere in an old archive.  As I remember, Stefan was one of the
people who had tried previously.  I believe someone else said they had
papers on file for it, but didn't according to the FSF records.  Anyhow,
the code I originally contributed was already better than the then
python-mode.el, after I couldn't get that fixed.  It also compared
favourably with the Eclipse mode and the Python IDE in Python, whose
name I forget.

Re: Current state of python.el in the Emacs trunk

[Dave Love]

Christoph <cschol2112@googlemail.com> writes:

> I'm confused. Didn't I offer to do maintenance work, like for example
> integrating Dave's bug fixes (if he agreed to it)?

I'm not sure what fixes you mean.  I've just maintained a separate
version.

> I have actually spent quite some time digging through the current
> python.el mode and tried to do some clean up and fix things.

That stuff simply shouldn't be there, which is why it originally wasn't.
It appears all the world's Python, so it doesn't matter if it causes
global problems and more-or-less excludes similar things for other
interpreters as far as I remember.  (I implemented a gud-minor-mode, of
course, but it required changes to gud.el and I didn't keep up with
Emacs.  I think the general facility was less code than the
Python-specific version.)

Re: Current state of python.el in the Emacs trunk

[Dave Love]

Fabian Ezequiel Gallina <galli.87@gmail.com> writes:

> It wasn't my plan to complicate things further, it was the approach
> that worked for me to solve the problem of my not-so-happy experience
> with the different python modes I tried.

What's wrong with mine, and did you report the problems?  If so, I don't
recall seeing it.

> Most of the stuff in trunk's python.el is there, so (I hope) your
> feeling remains that way :)

So how is this new mode better than mine, and where can I see it?

Re: Current state of python.el in the Emacs trunk

[Stephen J. Turnbull]

Dave Love writes:

 > Why?  python.el was intentionally different from python-mode.el for
 > various reasons, like being a well-behaved Emacs (as opposed to XEmacs?)
 > mode.

The people working on python-mode do seem to prefer XEmacs to a
certain extent, so I can understand why you might write something like
that, but I assure it's not very well-behaved by XEmacs standards,
either.  We do tend to be more lenient in those matters if somebody
volunteers to do the maintainance, though, unless it visibly impacts
other code.

Re: Current state of python.el in the Emacs trunk

[Stephen J. Turnbull]

Dave Love writes:

 > python.el code now seems to be migrating into python-mode.el (after
 > stripping the copyright headers, contrary to the licence, of
 > course).

Please add specific references to

            http://tracker.xemacs.org/XEmacs/its/issue753

and I'll do something about it in the XEmacs packaged version.  (I'll do
something about it eventually anyway, but it's not exactly top
priority for me personally; a lot of work for very little in return.)

Re: Current state of python.el in the Emacs trunk

[Stefan Monnier]

> I wasn't unwilling to maintain it, and I attempted in the past to get
> the Emacs version fixed and prevent problems being introduced, but that
> was rather unrewarding, and I gave up.

"I gave up" is basically what I meant by "unwilling to maintain".
If you prefer that I say "we were not willing to have him as maintainer
under the terms he wanted" that's perfectly fine by me: I do not care
about whose fault it is.  I only care about improving our python.el and
making sure it stays well maintained.

> If I was mainatinaing it, I'd just do what I've been doing separately,
> which doesn't seem acceptable.

I do not understand the above sentence.

> I haven't checked exactly what's
> currently in Emacs, but I'm baffled why, for instance, it got three
> .py files instead of a more maintainable one,

Presumably because, for lack of a maintainer, we integrate suboptimal
patches which solved incompatibilities between Python2 and Python3 by
splitting the file into two versions.

> and why changes were made which clearly broke things.

I don't know to which changes you're referring here.

> I don't know what that's about, but I maintain a version with no unfixed
> bugs I'm aware of, and had various features (and not misfeatures) the
> others don't.

But that does not help us much since (IIUC) you say that those changes
aren't covered by your assignment so we can't integrate them.

>> Of course, I'd rather work at bringing the various python modes closer
>> to each other, rather than have them fork even further, so I'm not sure
>> what's the best course here.

> Why?  python.el was intentionally different from python-mode.el for
> various reasons, like being a well-behaved Emacs (as opposed to XEmacs?)
> mode.  I don't understand why you'd want something whose distinction as
> far as I can tell is violating conventions with fewer features and extra
> bugs.

Bringing them closer to each other does not necessarily mean "take the
bad parts of python-mode.el".

BTW, regarding the global effect of pdbtrack, I agree that it's a bit
problematic, but at the same time this provides a form of integration
that some users really appreciate and which seems difficult to get
within something like GUD.
It'd be good to let users choose which one they want.


        Stefan

Re: Current state of python.el in the Emacs trunk

[Christoph]

Dave Love <fx@gnu.org> writes:

> I'm not sure what fixes you mean.  I've just maintained a separate
> version.

I was volunteering in case you were willing to let us incorporate any
fixes and improvements you made to your separate mode into the trunk but
couldnt or didnt want to do it yourself. The commentary of your file
says that certain bugs have been fixed, iirc.

> That stuff simply shouldn't be there, which is why it originally
> wasn't.

That's what I am currently working on cleaning up. This is mainly to
provide a cleaner base for the integration of functionality from
Fabian's new mode.

> It appears all the world's Python, so it doesn't matter if it causes
> global problems and more-or-less excludes similar things for other
> interpreters as far as I remember.  (I implemented a gud-minor-mode, of
> course, but it required changes to gud.el and I didn't keep up with
> Emacs.  I think the general facility was less code than the
> Python-specific version.)

I am unclear as to how gud-minor-mode would be better, since I am not
familiar with that mode at all. However, I remember reading in some old
thread where somebody made the point that Python's way of debugging
doesn't lend itself well to using a gud-minor-mode. I might have to go
back and reread that thread again.

Christoph

Re: Current state of python.el in the Emacs trunk

[ken manheimer]

[-- Attachment #1: Type: text/plain, Size: 7615 bytes --]

On Thu, Feb 24, 2011 at 1:13 AM, Christoph <cschol2112@googlemail.com>wrote:

> Dave Love <fx@gnu.org> writes:
>
> > I'm not sure what fixes you mean.  I've just maintained a separate
> > version.
>
> I was volunteering in case you were willing to let us incorporate any
> fixes and improvements you made to your separate mode into the trunk but
> couldnt or didnt want to do it yourself. The commentary of your file
> says that certain bugs have been fixed, iirc.
>
> > That stuff simply shouldn't be there, which is why it originally
> > wasn't.
>
> That's what I am currently working on cleaning up. This is mainly to
> provide a cleaner base for the integration of functionality from
> Fabian's new mode.
>
> > It appears all the world's Python, so it doesn't matter if it causes
> > global problems and more-or-less excludes similar things for other
> > interpreters as far as I remember.  (I implemented a gud-minor-mode, of
> > course, but it required changes to gud.el and I didn't keep up with
> > Emacs.  I think the general facility was less code than the
> > Python-specific version.)
>
> I am unclear as to how gud-minor-mode would be better, since I am not
> familiar with that mode at all. However, I remember reading in some old
> thread where somebody made the point that Python's way of debugging
> doesn't lend itself well to using a gud-minor-mode. I might have to go
> back and reread that thread again.
>
> Christoph


sorry it's about a month later, but i wasn't aware of these conversations
until this eve.  i expect that the point to which you're referring is mine,
stated in the message included below.  the upshot is that, in my
not-so-recent acquaintance with gud and gdb-oriented debugging, they're
oriented to be used as executives, running the program being debugged.  this
(if it is, in fact, the case) is extremely cumbersome and limited when it
comes to debugging very dynamic languages, where you may want to embark on
debugging in the middle of an already-executing run, dropping to an
interactive session when a traceback is encountered.  this is useful for
many programs, and crucial for long running servers (like zope, which was my
main focus when i developed pdbtrack for python-mode.el).

when i originally developed pdbtrack i looked at gud integration, and it was
horrifying.  i got 90% of what i needed by using a comint output filter
which noticed the python debugger's (pdb's) characteristic output and
fetched the corresponding files in another buffer, with the overlay-arrow on
the current line, and tracking execution as you interact with the python
debugger in whatever the shell is where it's running.  i did that with less
that 150 lines of elisp lines, including a lot of comments.  i depend on it
daily when debugging python within emacs, and i think many other emacs /
python users do, too.

i was spurred to speak up when dave suggested in the thread (as i excerpted
in the following message) that "it's not difficult to restructure GUD" to
provide the functionality, and therefore "and it's not clean to make an
add-on, which is why it's [pdbtrack, i believe] not in python.el".  it
sounded like, by suggesting providing the functionality with gud, dave was
missing and/or dismissing some central features which make pdbtrack useful.
 i can see making it easy to disable for the people who don't want to use
it, but making it unavailable for those who need it was a very frustrating
prospect.  however, pdbtrack does seem to be present in the versions of
python.el that come with emacs 23 on the various systems i use, so i'm
hopeful it's been adopted and will continue to be.

ken

---------- Forwarded message ----------
From: ken manheimer <ken.manheimer@gmail.com>
Date: Thu, Feb 19, 2009 at 3:21 PM
Subject: Re: replacing python.el
To: Dave Love <fx@gnu.org>
Cc: Glenn Morris <rgm@gnu.org>, "skip@pobox.com" <skip@pobox.com>, "
rms@gnu.org" <rms@gnu.org>, "python-mode@python.org" <python-mode@python.org>,
"XEmacs-Beta@xemacs.org" <XEmacs-Beta@xemacs.org>, "barry@python.org" <
barry@python.org>, "fbe2@comcast.net" <fbe2@comcast.net>, "
emacs-devel@gnu.org" <emacs-devel@gnu.org>


sorry to be late to this python.el / python-mode.el convergence
discussion.  i'm concerned that what dave is describing would not
preserve a crucial feature of pdbtrack, a feature that may be a reason
some python developers choose python-mode.el over python.el.  (it is
for me.)

On Sun, Feb 1, 2009 at 3:51 PM, Dave Love <fx@gnu.org> wrote:
>[...]
> Indeed, and I don't understand what other problem there is with it,
> other than maintenance.  Why does it need to be replaced with
> python-mode.el, even if that was properly assigned?
>
> The only other worthwhile feature I know of sort-of from python-mode.el
> is related to something called pdbtrack (?).  My commentary explains
> that part of the functionality already exists, and something more
> general than the rest should be a general feature in GUD.  (The
> Python-specifics are already there.)  It's not difficult to restructure
> GUD -- or wasn't when I hacked it originally -- and it's not clean to
> make an add-on, which is why it's not in python.el.  I know there isn't
> interest in abstractions like that, but I didn't want to preempt a
> possible change of opinion.

when i last looked at it, gud was a terrible fit for pdbtrack.  if
things haven't changed drastically,  i'm concerned that what you're
suggesting would sacrifice pdbtrack's dynamicism.

this is all the more worrisome since i spent some time porting
pdbtrack to python.el.  it's currently there in emacs 23.0.90, but i
see it's not in the emacs that comes w/recent ubuntu, emacs 22.2.

here's the scoop, as best i can describe it.

gud is oriented to being in control of debugging, in particular
launching the program being debugged, or injecting a connection to
the executive to start the debugging at an arbitrary point, or
post-mortem.

pdbtrack, on the other hand, simply works wherevever python's
debugger, pdb, does.  the pdbtrack code is responsible for detecting
pdb activity within an (any) emacs shell and presenting, in a
companion buffer,  the source file and line that pdb is reporting as
the current instruction.

pdbtrack provides functionality for python's debugger, pdb, much like
edebug does for emacs lisp, except that pdb can be triggered as a
statement within the subject program's code, and not just taking over
execution of the program (as gdb and edebug do), or run
onerror/post-mortem.  (pdb also provides those modes.)  this turns out
to be invaluable in general, and especially for long-running programs
like servers, where you want debugging to trigger in very specific
situations.  with pdb, you just situate the debug-triggering code
exactly in the situation (i wish i could do this with edebug), or as
error handling around the situation.

gud may have facilities that could be used to enhance pdbtrack, but i
don't think it is designed to operate the way i describe above.  plus,
gud is massive, and i suspect it would take more emacs lisp code to
craft gud python accommodations than all of pdbtrack (last i checked
around 150 lines, including copious comments).

i hope this is clear.  as i said, pdbtrack porting to python.el has
already been done, it just isn't in the currently released version.
and, of course, there are other benefits to be had from a
python-mode.el/python.el convergence, but i want to make sure this
one, at least, is preserved.  (i also think the pdbtrack approach
would be appreciated for other dynamic languages, including emacs
lisp.)
--
ken
http://myriadicity.net


>

[-- Attachment #2: Type: text/html, Size: 10669 bytes --]

Re: Current state of python.el in the Emacs trunk

[Stefan Monnier]

> prospect.  however, pdbtrack does seem to be present in the versions of
> python.el that come with Emacs 23 on the various systems i use, so i'm
> hopeful it's been adopted and will continue to be.

There's no plan to remove it, indeed.  Its global impact is a bit
problematic but that's no argument for removing the feature since it's
not a bug of the implementation but is part of the intended UI.


        Stefan

Re: Current state of python.el in the Emacs trunk

[Fabian Ezequiel Gallina]

2011/3/29 Stefan Monnier <monnier@iro.umontreal.ca>:
>> prospect.  however, pdbtrack does seem to be present in the versions of
>> python.el that come with Emacs 23 on the various systems i use, so i'm
>> hopeful it's been adopted and will continue to be.
>
> There's no plan to remove it, indeed.  Its global impact is a bit
> problematic but that's no argument for removing the feature since it's
> not a bug of the implementation but is part of the intended UI.
>

FWIW the python.el I'm proposing contains a pretty short pdbtrack
implementation[0].

[0] https://github.com/fgallina/python.el/blob/master/python.el#L1413

(sorry Stefan for the double email)

Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com

Re: Current state of python.el in the Emacs trunk

[Christoph Scholtes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> prospect.  however, pdbtrack does seem to be present in the versions of
>> python.el that come with Emacs 23 on the various systems i use, so i'm
>> hopeful it's been adopted and will continue to be.
>
> There's no plan to remove it, indeed.  Its global impact is a bit
> problematic but that's no argument for removing the feature since it's
> not a bug of the implementation but is part of the intended UI.

I actually like the idea of pdbtrack quite a bit and like Stefan said,
there is no plan to remove it. Fabian's implementation works really nice
and also handles all corner cases well, for example the end of the
script being debugged. The current pdbtrack implementation would end up
in emacs2.py when stepping past the end of the script.

Christoph