SET_LINENO

[Bruce Dawson]

Thanks for all the replies - including the link to the unhandled 
exception handling option.

Martin v. Löwis wrote:

> Bruce Dawson <bruce_deletethis_dawson at cygnus-software.com> writes:
> 
> 
>>Executive summary: Has the SET_LINENO removal been tested with the HAP
>>debugger, and wouldn't a breakpoint instruction give much larger
>>benefits?

...


>>So, wouldn't a break-point opcode be a more substantial improvement
>>than removing SET_LINENO? Just bringing up that old topic again to see
>>if it gets any more traction :-)
>>
> 
> No. Removal of SET_LINENO does improve performance in a "free-running"
> application, which adding a breakpoint instruction would not.

A breakpoint instruction would be intended to improve performance in 
debuggers. My point was that the improvement there would be larger 
(probably 100% or more) than the improvement from SET_LINENO. But the 
improvement would not, as you say, affect "free-running" applications at 
all.


> That said: it might be still worthwhile to add a breakpoint
> instruction. There are a number of issues to be considered, such as
> getting the breakpoint instruction into the byte code, and getting the
> original instruction back in. So if you'ld like to see one, you
> probably have to write a PEP.


Some day I will do that. I have to dig deeper in the Python source 
before I can do that.


> 
>>P.P.S. A breakpoint instruction would also be a boon for asserts - I'd
>>love to be able to stop on the assert when running under a debugger,
>>to see what is wrong before the stack frame unwinds.
>>
> 
> I can't see how this helps. Wouldn't you have to set a breakpoint on
> all asserts for that? And wouldn't that require finding all asserts in
> the first place?

If assert was implemented with a hard-coded breakpoint then it would 
work very nicely. Under a debugger this would stop you on the relevant 
line. Not under the debugger it would throw an exception as before.

On x86 processors int 3 is the hard-coded breakpoint instruction. If you 
hit one it stops your program. If you're running under a debugger you 
can then step right over it. I was imagining something like that.

Asserts are great, but they are easier to interpret if when you trigger 
one you are dropped onto the assert statement. Just a mad idea...