[Python-Dev] seeing off SET_LINENO

[Guido van Rossum]

> Well, if there's code there, then the debugger stops.  I know it's
> confusing to have intuitive behaviour in this area...

:-)

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

Agreed.

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

I don't care if it slows down tracing, but I'd like it not to slow
down regular operation.  Of course, since SET_LINENO is gone, it
should speed things up dramatically; but how does it do compared to
previous -O mode?  (I guess the only difference that -O makes now is
that asserts aren't compiled. :-)

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

I'm not too attached to LLTRACE.  As long as it's usable for debugging
massive changes to the VM implementation I'm okay with it.

--Guido van Rossum (home page: http://www.python.org/~guido/)