[Python-Dev] SET_LINENO and python options
Mon, 31 Jul 2000 14:47:09 -0400 (EDT)
On Sun, 30 Jul 2000, Ka-Ping Yee wrote:
> On Sat, 29 Jul 2000, Ken Manheimer wrote:
> > On Fri, 28 Jul 2000 Vladimir.Marangozov@inrialpes.fr wrote:
> > > 1) python - code without SET_LINENO
> > > 2) python -g - code for debugging, with SET_LINENO
> > > 3) python -O - code without doc-strings.
> > I would be firmly -1 on this proposal.
> Funny -- i was just about to throw in a hearty +1.
> > I see the ability to debug at whim, even when you didn't expect having to
> > do so, as being a major win, part of the incremental development process.
> But you *can't* debug at whim, right? You have to have started the
> debugger, so it can hook sys.settrace, before you run your program.
> If you have to start the debugger anyway, then you can surely say -g.
More often than not, if i'm developing something substantial, then my
interpreter sessions will involve developing context, running something
then having it fail, doing a pdb.pm() post mortem, and then doing a second
run with pdb.run(). My life would be worse if i happened to forget to
start python with the '-g' in the first place.
This scenario happens even when i don't intend to be "developing", ie when
i encounter bugs in random code i'm using. As it stands, i (and anyone)
have recourse to poke around at will. This is the kind of thing that
makes an interpreted language valuable to me in the first place, and why
i'm willing to trade of a lot more than a few percent performance.
(This all may be moot if the linenotab-based alternative pans out - then
everyone can be happy.)
> Let's suppose:
> 1. -g is turned on by default in interactive mode, since we
> don't know if you're going to feel like tracing today.
This would address my above concerns.
> 2. Programs (like debuggers and IDEs) that know they're going
> to use sys.settrace, or which contain embedded interactive
> interpreters, begin with
> #!/usr/bin/env python -g
> 3. Other programs begin with the usual
> #!/usr/bin/env python
> Given this -- are there any debugging opportunities you're missing
> out on? I don't see any...
One important one would be connecting with a long-running process, eg
something running under medusa via the medusa monitor client.
Unfortunately, it looks like the monitor client currently doesn't use a
pty, or uses it wrong, or something, so the debugger doesn't work right
anyway - which has been a royal pain on many occasions!
I could see it being worthwhile to run the server process in an economy
mode, if the economy were big. For some definition of big, of course.-)