Minor updates.

pep-0280.txt

@@ -383,15 +383,16 @@ Additional Ideas
                 # We're shadowing it already.
                 assert not c.builtinflag
 
-    Changing the value of an existing builtin can be viewed as deleting
-    the name, then adding it again.  Indeed, since mutating builtins is
-    so rare, that's probably the right way to implement it too (speed
-    doesn't matter here):
+    Changing the value of an existing builtin:
 
         def reflect_bltin_change(self, key, newvalue):
-            assert key in self.__dict
-            self.reflect_bltin_del(key)
-            self.reflect_bltin_new(key, newvalue)
+            c = self.__dict.get(key)
+            assert c is not None # else we were already out of synch
+            if c.builtinflag:
+                # Put us back in synch.
+                c.objptr = newvalue
+            # Else we're shadowing the builtin, so don't care that
+            # the builtin changed.
 
 
 FAQs
@@ -399,7 +400,7 @@ FAQs
     Q. Will it still be possible to:
        a) install new builtins in the __builtin__ namespace and have
           them available in all already loaded modules right away ?
-       b) override builtins (e.g. open()) with my own copies 
+       b) override builtins (e.g. open()) with my own copies
           (e.g. to increase security) in a way that makes these new
           copies override the previous ones in all modules ?
 
@@ -417,7 +418,11 @@ FAQs
     Q. What happens when a global is deleted?
 
     A. The module's celldict would have a cell with a NULL objptr for
-       that key.
+       that key.  This is true in both variations, but the "aggressive"
+       variation goes on to see whether this unmasks a builtin of the
+       same name, and if so copies its value (just a pointer-copy of the
+       ultimate PyObject*) into the cell's objptr and sets the cell's
+       builtinflag to true.
 
     Q. What would the C code for LOAD_GLOBAL_CELL look like?
 
@@ -455,6 +460,18 @@ FAQs
        cell->cellptr is the same as cell for regular globals and hence
        this should be very fast in that case too.
 
+       For the aggressive variant:
+
+       case LOAD_GLOBAL_CELL:
+           cell = func_cells[oparg];
+           x = cell->objptr;
+           if (x != NULL) {
+               Py_INCREF(x);
+               continue;
+           }
+           ... error recovery ...
+           break;
+
     Q. What happens in the module's top-level code where there is
        presumably no func_cells array?