[Python-Dev] Reordering opcodes (PEP 203 Augmented Assignment)

[Ka-Ping Yee]

Mark Hammond wrote:
> 
> > Can someone summarise what the issues are with SET_LINENO?
> > I had the impression that they're not needed for finding the
> > line numbers in tracebacks.

Yes, traceback info comes from c_lnotab and doesn't depend on
SET_LINENO.  Only tracing and f.lineno depend on SET_LINENO.

> > So what would we lose if they disappeared?
> 
> The debugger (and quite possibly the profiler - I havent checked!)

I'm still a little puzzled on this one.  The only way you can view
a running Python program in the debugger is to have started it
within the debugger, right?  I don't think it's possible to attach
a debugger to an already running program.

Hence -- if you had to know beforehand that you were going to start
the debugger anyway, then you clearly have the opportunity to say -g
whenever you want to do debugging.  It seems to me that any debugger
(or IDLE et al.) can just start with

    #!/usr/bin/env python -g
    
and we could then drop SET_LINENO by default.  Am i missing something?


On Mon, 31 Jul 2000, Vladimir Marangozov wrote:
> Note that the f.lasti attr is not updated as it should in the main loop,
> because it would infer a lot of overhead (to be up to date, it needs to
> be updated for every opcode). It is updated only for 'important' events:
> a trace hook, an exception, a Python function call.

This is okay.  The *only* time this is going to make any difference
is when a function is trying to inspect the location of the PC within
itself.  (When the frame is being inspected from anywhere else, f.lasti
will be up to date because it will have been set on function call.)

I think we don't need to care so much about a function looking at its
own f.lineno.  Just use PyCode_Addr2Line on f.lasti whenever someone
asks for f.lineno, and perhaps document the caveat for anyone weird
enough to write navel-gazing functions. :)


-- ?!ng