Thank you for your very thoughtful and detailed explanation of what is going on and for your considerations as to how to get this done (as opposed to why it <i>can't </i>be done). <div><br></div><div>It looks like DecoratorTools or more likely a customized version of it is the way to go!</div>
<div><br></div><div>(The important info is above. The rest are just some geeky details)</div><div><br></div><div>You see, there are some places where additional care may be needed in my setting. </div><div><br></div><div>
The debuggers I write use sometimes don't use just the getline module but also use my own pyficache module. I want to also cache things like file stat() info, provide a SHA1 for the text of the file, and provide colorized syntax-highlighted versions of the text when desired. But since I control pyficache, I can mirror the changes made to getline.</div>
<div><br></div><div><div><div>Of course the debugger uses sys.settrace too, so the evil-ness of that is definitely not a concern. But possibly I need to make sure that since the DecoratorTools and the debugger both hook into trace hooks they play nice together and fire in the right order. And for that I created another module called tracer() which takes into account that one might want to specify priorities in the chain hook order, and that one might want a to filter out (i.e. ignore) certain calls to the hook function for specific hooks. </div>
<div><br></div><div>It may be a while before I seriously get to this, but again, it is good to have in mind an approach to take. So thanks again.<br><br><div class="gmail_quote">On Thu, Mar 28, 2013 at 1:45 AM, PJ Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com" target="_blank">pje@telecommunity.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Mar 26, 2013 at 11:00 PM, Rocky Bernstein <<a href="mailto:rocky@gnu.org">rocky@gnu.org</a>> wrote:<br>

> Okay. But is the string is still somewhere in the CPython VM stack? (The<br>
> result of LOAD_CONST 4 above). Is there a way to pick it up from there?<br>
<br>
</div>Maybe using C you could peek into the frame's value stack, but that's<br>
not exposed to any Python API I know of.  But that still doesn't help<br>
you, because the value will be removed from the stack before exec() is<br>
actually called, which means if you go looking for it in code called<br>
from the exec (e.g. the call event itself), you aren't going to see<br>
the data.<br>
<div class="im"><br>
> At the point that we are stopped the exec action hasn't taken place yet.<br>
<br>
</div>That doesn't help if you're using line-level tracing events.  At the<br>
beginning of the line, the data's not on the call stack yet, and by<br>
the time you enter the frame of the code being exec'd, it'll be off<br>
the stack again.<br>
<br>
Basically, there is no way to do what you're asking for, short of<br>
replacing the built-in exec function with your own version.  And it<br>
still won't help you with stepping through the source of functions<br>
that are *compiled* using an exec() or compile(), or any other way of<br>
ending up with dynamically-generated code you want to debug.<br>
<br>
(Unless you use something like DecoratorTools to generate it, that is<br>
-- DecoratorTools has some facilities for caching<br>
dynamically-generated code so that it works properly with debuggers.<br>
But that has to be done by the code doing the generation, not the<br>
debugger.  If the code generator uses DecoratorTools' caching support,<br>
then any debugger that uses the linecache module will Just Work.  It<br>
might be nice for  the stdlib should have something like this, but you<br>
could also potentially fake it by replacing the builtin eval, exec,<br>
compile, etc. functions w/versions that cache the source.)<br>
</blockquote></div><br></div></div></div>