FAQ
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...

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 8 | next ›
Discussion Overview
grouppython-list @
categoriespython
postedSep 26, '02 at 6:09a
activeSep 27, '02 at 10:37a
posts8
users6
websitepython.org

People

Translate

site design / logo © 2022 Grokbase