_nr and callbacks Re: Is Stackless Python DEAD?
mwh at python.net
Tue Nov 6 16:09:23 CET 2001
"Frederic Giacometti" <frederic.giacometti at arakne.com> writes:
> "Michael Hudson" <mwh at python.net> wrote in message
> news:uady09pkm.fsf at python.net...
> > Martin von Loewis <loewis at informatik.hu-berlin.de> writes:
> > [schnipp]
> > > * Are the _nr versions functionally completely backwards-compatible?
> > > If not, why? If yes, why is the original version preserved?
> > I think the originals are just around because the implementation of
> > the _nr variants was tricky and Chris needed something to test
> > against. Not sure, though.
> From what I understand in the stackless mechanism, the _nr functions are
> used in the Python VM, but cannot be used in C extension callbacks.
> In effect, in C extensions (or when embeding Python), Python must return to
> the C code after executing the callback. So, distinct hybrid functions,
> different from those used by the VM, are still needed.
Huh? The builtin_foo functions in Python/bltinmodule.c are all
declared static, so you can't call them from C extensions anyway. You
could grub around in __builtins__ and call them using
PyEval_CallObject or whatever, but do people actually do this?
You could still "call" the _nr variants, but any "call" of a C
function that might end up calling Python code (i.e. almost anything
in the Python C API!) must actually be structured as a
stack-push-then-return wotsit like I tried (and probably failed) to
explain in the quoted post.
> It's true that stackless introduces an additional level of complexity, and
> that its implementation could be lifted up. These can be the actual reasons
> why this has not been merged...
I think Gordon's post got the nail on the head here.
 If continuations are to be allowed to escape from the called
Python code, anyway.
Any form of evilness that can be detected without *too* much effort
is worth it... I have no idea what kind of evil we're looking for
here or how to detect is, so I can't answer yes or no.
-- Guido Van Rossum, python-dev
More information about the Python-list