Guido van Rossum <guido@python.org> writes:
> > After my patch there are no SET_LINENO opcodes, so execution is
> > never on the def line[*], so no 'line' trace event is generated for
> > the def line, so a debugger that only listens to the 'line' events and
> > ignores the 'call' events will not stop on that line.
>
> If the argument list contains embedded tuples, there's code executed
> to unpack those before the first line of the function.
Well, if there's code there, then the debugger stops. I know it's
confusing to have intuitive behaviour in this area...
> Example:
>
> >>> def f(a, (b, c), d):
> ... print a, b, c, d
> ...
> >>> f(1, (2, 3), 4)
> 1 2 3 4
> >>> f(1, 2, 3)
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File "<stdin>", line 1, in f
> TypeError: unpack non-sequence
> >>>
>
> I hope the debugger will stop *before* this unpacking happens! It
> does now:
>
> >>> import pdb
> >>> pdb.run("f(1, 2, 3)")
> > <string>(0)?()
> (Pdb) s
> > <string>(1)?()
> (Pdb)
> > <stdin>(1)f()
> (Pdb)
> TypeError: 'unpack non-sequence'
> > <stdin>(1)f()
> (Pdb) q
> >>>
Still does:
$ cat t.py
def f(a, (b, c), d):
print a, b, c, d
$ ./python
Python 2.3a0 (#14, Aug 1 2002, 16:48:20)
[GCC 2.96 20000731 (Red Hat Linux 7.2 2.96-108.7.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb, t
>>> pdb.run("t.f(1, 2, 3)")
> <string>(1)?()
(Pdb) s
> /home/mwh/src/sf/python/dist/src/build/t.py(1)f()
-> def f(a, (b, c), d):
(Pdb)
TypeError: 'unpack non-sequence'
> /home/mwh/src/sf/python/dist/src/build/t.py(1)f()
-> def f(a, (b, c), d):
(Pdb) q
Anyway, I think I'm done now (as you maybe able to tell from the pile
of patch notification emails than just landed in your inbox :).
These issues from my original mail in this thread still haven't be
addressed:
4) The patch installs a descriptor for f_lineno so that there is no
incompatibility for Python code. The question is what to do with
the f_lineno field in the C struct? Remove it? That would
(probably) mean bumping PY_API_VERSION. Leave it in? Then its
contents would usually be meaningless (keeping it up to date would
rather defeat the point of this patch).
I think leaving f_lineno there but useless is the way to go. If we
actually make incompatible changes for other reasons, then it can
disappear.
8) I haven't measured the performance impact of the changes to code
that is tracing or code that isn't. There's a possible
optimization mentioned in the patch for traced code. For not
traced code it MAY be worthwhile putting the tracing support code
in a static function somewhere so there's less code to jump over in
the main loop (for i-caches and such).
Still haven't done this.
9) This patch stops LLTRACE telling you when execution moves onto a
different line. This could be restored, but
a) I expect I'm the only persion to have used LLTRACE recently
(debugging this patch).
b) This will cause obfuscation, so I'd prefer to do it last.
No change here either.
Cheers,
M.
--
The gripping hand is really that there are morons everywhere, it's
just that the Americon morons are funnier than average.
-- Pim van Riezen, alt.sysadmin.recovery
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