Also show C pseudo-code of Tim's version.
This commit is contained in:
parent
9c4c598a79
commit
b710da4bee
20
pep-0280.txt
20
pep-0280.txt
|
@ -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?
|
||||
|
||||
|
|
Loading…
Reference in New Issue