>>>>> "MH" == Michael Hudson <mwh@python.net> writes:
MH> Hmm, I hadn't actually dared to run pdb with my patch... have
MH> now, and it seems OK.
Cool.
MH> There is a difference:
MH> The bytecode for, say,
| def f():
| print 1
MH> begins with two SET_LINENO's. One is for the line containing
MH> "def f():", one is for "print 1". My patch means the debugger
MH> doesn't stop on the "def f():" line -- unsurprisingly, given
MH> that no execution ever takes place on that line.
MH> It would be possible to force a call to the trace function on
MH> entry to the function. In fact, there's a commented out block
MH> for this in my patch. Another approach would presuambly be
MH> for pdb to stop on 'call' trace events as well as 'line' ones.
MH> I don't really understand, or use all that often, pdb.
I can't decide whether it would be good to stop on the def or not.
Not doing so makes pdb act more like gdb, which also only stops on the
first executable line, so maybe that's a good thing.
MH> Also, you currently stop twice on the first line of a for
MH> loop, but only once with my patch.
That /is/ a good thing!
>> Have you tested how this change might interact with
>> e.g. hotshot?
MH> test_hotshot was very important to me as evidence I was making
MH> progress!
:)
MH> It currently fails due to the not-calling-trace-on-def-line
MH> issue, but as I said, I think this is a *good* thing...
So maybe we need two different behaviors depending on whether we're
debugging or profiling. That might get a bit kludgy if we're using
the same trace mechanism for both, but I'm sure it's tractable.
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4