<div class="gmail_quote">On Tue, Nov 27, 2012 at 10:33 PM, Trent Nelson <span dir="ltr"><<a href="mailto:trent@snakebite.org" target="_blank">trent@snakebite.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    In this case though, a step of an eval frame would wildly jump<br>
    to seemingly unrelated parts of C code.  As far as I could tell,<br>
    there was no easy/obvious way to figure the details out before<br>
    stepping that instruction either (i.e. probing the various locals<br>
    and whatnot).<br></blockquote><div> </div><div>I'm not sure that has anything to do with "yield from", but rather to do
 with the use of computed gotos 
(<a href="http://hg.python.org/cpython/file/default/Python/ceval.c#l821">http://hg.python.org/cpython/file/default/Python/ceval.c#l821</a>). For 
sane stepping in the eval loop, you probably want to build with 
"--without-computed-gotos" enabled (that's a configure option on Linux, I
 have no idea how to turn it off on Windows). Even without that, the 
manual opcode prediction macros are still a bit wacky (albeit easier to 
follow than the compiler level trickery).<br><br>The eval loop commits many sins against debuggability and maintainability in pursuit of speed, so it's not really fair to place all of that at the feet of the yield from clause.<br>
<br>if you really did just mean the behaviour of jumping from caller-frame-eval-loop to generator-frame-eval-loop and back out again, then that again is really just about generator stepping at the C level (where suspend/resume means passing through ceval.c), rather than being specific to yield from.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
    So, that's the main feedback from that weekend, I guess.  Granted,<br>
    it's more of a commentary on `yield from` than tulip per se, but I<br>
    figured it would be worth offering up my experience nevertheless.<br></blockquote><div><br>From your description so far, it seems like more of a commentary on pointing a C level debugger at our eval loop... <br></div>
<div><br>Cheers,<br>Nick.<br><br></div><div>-- <br></div></div>Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>