yeah, i did think native functions wouldn't fit well with it, but then
again, i don't plan to have any c-side functions invoking python
callbacks. i can live with that. but, alas, ceval::EvalFrameEx will
clear the execution stack upon returning [1], so this couldn't work
anyway [2].
[1]
while (STACK_LEVEL() > b->b_level) {
v = POP();
Py_XDECREF(v);
}
[2] hrrrmpff
-tomer
On Dec 15, 2007 6:57 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 01:04 AM 12/15/2007 -0800, tomer filiba wrote:
> >* do you suppose it will work? are there any drawbacks i didn't
> >anticipate?
>
> Yes. :)
>
> Specifically, think about what happens when a C function is in the
> call stack, e.g.:
>
> def f1():
> return map(f2, [1,2,3])
>
> def f2(ob):
> raise WaitFor(something)
> return ob
>
> print f1()
>
> If I understand you correctly, when this program is run, it will
> print "1", rather than "[1, 2, 3]", because there is no way for you
> to keep track of the internal state of the 'map()' call.
>
> And this isn't just a problem for map() -- even something as simple
> as a property access passes through C code whose state can get lost.
>
> I don't think this approach is practical; you'd be better off using a
> co-routine stack and trampoline, since the nature of generators
> naturally forces all the C code out of the picture.
>
>
--
An NCO and a Gentleman
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
