[Python-Dev] seeing off SET_LINENO

[Michael Hudson]

Guido van Rossum <guido@python.org> writes:

> > I've found another annoying problem.  I'm not really expecting someone
> > here to sovle it for me, but writing it down might help me think
> > clearly.
> > 
> > This is about the function epilogues that always get generated.  I.e:
> [...]
> > The debugger stopping on the "print 1" is confusing.
> > 
> > There's an "obvious" solution to this: check it we're less than 4
> > bytes from the end of the code string and don't do anything if we are.
> 
> Um, I think that's less than reliable.  I believe we just discussed
> this when Oren's patch for yield in try/finally did a similar thing
> (and weren't you the one who mentioned that your bytecodehacks can
> cause this assumption to fail? :-).

Good point.

> I'm not actually sure that this needs fixing.  Surely the --Return--
> should be a sufficient hint.  I note that without your patch it also
> stops at a confusing place, albeit a different one (on the "if a:"
> line).

The problem is that when we jump into the epilogue, a 'line' trace
event gets generated before the 'return' one.  So there is no
--Return-- hint.

> > This would be easy, except that for some bonkers reason, we support
> > arbitrary buffer objects for code strings!  (see _PyCode_GETCODEPTR in
> > Include/compile.h -- though at least you can't create a code object
> > with an array code string from python, the getreadbuffer failing will
> > cause the interpreter to unceremoniously crash and burn).
> 
> That went a little too fast.  Can you explain that parenthetical
> remark more clearly?

1) Don't you find the idea of type(co.co_code) == types.ArrayType at
   least a little scary?  Mainly due to resizes -- having mutable code
   might be nice for development environments and such.

2) I thought it was possible for bf_getreadbuffer to fail (maybe I'm
   wrong here).  _PyCode_GETCODEPTR does no error checking.

> > I guess I can store the length somewhere -- _PyCode_GETCODEPTR returns
> > this, more by accident than design I suspect -- or call
> > bf_getsegcount(frame->f_code->co_code, &length) or something.
> > 
> > Does anyone actually *use* this feature?  I see Guido checked it in
> > and the patch was written by Greg Stein.  Anyone remember motivations
> > from the time?
> 
> Yes, Greg insisted that he might want to store Python bytecode in
> Flash ROM, and that this way the bytecode would not have to be copied
> to RAM.

I see.

> But I don't think this ever happened

Gosh.

> (well, maybe the now-dead Pippy port to PalmOS used it???).

Maybe.  Somehow doubt it, though.

> I'd be happy to kill it as a YAGNI.

That's nice, but if...

> But that still doesn't mean I approve checking for "4 bytes from the
> end".

...it doesn't actually help.

Does anyone have any better ideas for not generating 'line' trace
events in the epilogue?

Cheers,
M.

-- 
  I also feel it essential to note, [...], that Description Logics,
  non-Monotonic Logics, Default Logics and Circumscription Logics 
  can all collectively go suck a cow. Thank you.
              -- http://advogato.org/person/Johnath/diary.html?start=4