yes, well, as i suspected and as PJE pointed out, extension or builtin functions would <br>make life difficult, but these are difficulties i would be willing to accept. however, my attempts<br>are futile anyways, as the evaluation stack is cleared before the exception propagates up
<br>to the frames above... which would explain the NULL deref exceptions i was getting :)<br><br><br>-tomer<br><br><div class="gmail_quote">On Dec 16, 2007 12:54 AM, Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz">
greg.ewing@canterbury.ac.nz</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">tomer filiba wrote:<br>> the idea i came up with is, using exceptions for functional
<br>> continuations: after all, the exception's traceback holds the entire<br>> context...<br><br>The problem with this is that, if the call chain has passed<br>through a C-implemented function at some point, the traceback
<br>*doesn't* contain the entire context -- some of it is in the<br>C stack frames that got unwound during the propagation of<br>the exception.<br><br>So you may be able to make this work where all the code<br>involved is pure Python, but it can't work in general,
<br>unless you redesign the whole interpreter the way the<br>original Stackless did.<br><br>Having said that, it might still be a useful thing to<br>have, as the pure-Python case is probably fairly common.<br>But I'd want to know what the failure mode is like when
<br>the pure-Python case doesn't hold. Do you get a clear<br>indication of what is wrong, or does it misbehave in<br>some obscure way?<br><br>A test case for this would be to call map() with a<br>function that tries to suspend itself using this
<br>mechanism. What happens when you try to resume it?<br><br>--<br><font color="#888888">Greg<br></font></blockquote></div><br><br clear="all"><br>-- <br>An NCO and a Gentleman