[Python-ideas] WSAPoll and tulip

[Nick Coghlan]

On Tue, Nov 27, 2012 at 10:33 PM, Trent Nelson <trent at snakebite.org> wrote:

>     In this case though, a step of an eval frame would wildly jump
>     to seemingly unrelated parts of C code.  As far as I could tell,
>     there was no easy/obvious way to figure the details out before
>     stepping that instruction either (i.e. probing the various locals
>     and whatnot).
>

I'm not sure that has anything to do with "yield from", but rather to do
with the use of computed gotos (
http://hg.python.org/cpython/file/default/Python/ceval.c#l821). 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).

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.

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.

    So, that's the main feedback from that weekend, I guess.  Granted,
>     it's more of a commentary on `yield from` than tulip per se, but I
>     figured it would be worth offering up my experience nevertheless.
>

>From your description so far, it seems like more of a commentary on
pointing a C level debugger at our eval loop...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121128/88efb791/attachment.html>