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