"M.-A. Lemburg" <mal@lemburg.com> writes: > > begins with two SET_LINENO's. One is for the line containing "def > > f():", one is for "print 1". My patch means the debugger doesn't stop > > on the "def f():" line -- unsurprisingly, given that no execution ever > > takes place on that line. > > This might be used in debugging application to setup some > environment *before* diving into the function itself. So do that when you get the 'call' trace function call! That's what it's there for. > Note that many C debuggers stop at the declare line of > a function as well (because they execute stack setup code), > so a sudden change in this would probably confuse users of > todays Python IDEs. However, sudden changes here are *very* likely to confuse, I agree. Perhaps bug-compatibility is something to aim for. [...] > >>Have you tested how this change might interact with e.g. hotshot? > > > > > > test_hotshot was very important to me as evidence I was making > > progress! > > > > It currently fails due to the not-calling-trace-on-def-line issue, but > > as I said, I think this is a *good* thing... > > Have you also tested this with the commonly used Python IDEs > out there ? E.g. IDLE, IDLE-fork, PythonWorks, WingIDE, Emacs, > BlackAdder, BOA Constructor, etc. etc. No. Don't think it's relavent to IDLE (at least, I can't see any calls to settrace in there that aren't commented out). Python-mode's pdbtrack should just carry on working. Don't have easy access to the others. I'd be amazed if other IDE's were severely adversely affected. Anyway, isn't this what alphas are for? I have no problem emailing a relavent person for each of the above IDEs and pointing out that this change may affect them. Cheers, M. -- If a train station is a place where a train stops, what's a workstation? -- unknown (to me, at least)
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