Also show C pseudo-code of Tim's version.

This commit is contained in:
Guido van Rossum 2002-02-11 15:48:50 +00:00
parent 9c4c598a79
commit b710da4bee
1 changed files with 18 additions and 2 deletions

View File

@ -407,7 +407,7 @@ FAQs
approach, when LOAD_GLOBAL_CELL finds a NULL in the second
cell, it should go back to see if the __builtins__ dict has
been modified (the pseudo code doesn't have this yet). Tim's
alternative also takes care of this.
"more aggressive" alternative also takes care of this.
Q. How does the new scheme get along with the restricted execution
model?
@ -421,7 +421,10 @@ FAQs
Q. What would the C code for LOAD_GLOBAL_CELL look like?
A. case LOAD_GLOBAL_CELL:
A. The first version, with the first two bullets under "Additional
ideas" incorporated, could look like this:
case LOAD_GLOBAL_CELL:
cell = func_cells[oparg];
x = cell->objptr;
if (x == NULL) {
@ -434,6 +437,19 @@ FAQs
Py_INCREF(x);
continue;
With Tim's "more aggressive" alternative added, it could look
like this:
case LOAD_GLOBAL_CELL:
cell = func_cells[oparg];
x = cell->objptr;
if (x == NULL) {
... error recovery ...
break;
}
Py_INCREF(x);
continue;
Q. What happens in the module's top-level code where there is
presumably no func_cells array?