[Python-Dev] seeing off SET_LINENO

[Michael Hudson]

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