bruce_deletethis_dawson at cygnus-software.com
Thu Sep 26 17:34:02 CEST 2002
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
>>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
> 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...
More information about the Python-list