[Python-checkins] CVS: python/nondist/peps pep-0280.txt,1.11,1.12

2002年2月11日 16:01:37 -0800

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv25638
Modified Files:
	pep-0280.txt 
Log Message:
Minor updates.
Index: pep-0280.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0280.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -d -r1.11 -r1.12
*** pep-0280.txt	11 Feb 2002 16:24:10 -0000	1.11
--- pep-0280.txt	12 Feb 2002 00:01:35 -0000	1.12
***************
*** 384,396 ****
 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):

 def reflect_bltin_change(self, key, newvalue):
! assert key in self.__dict
! self.reflect_bltin_del(key)
! self.reflect_bltin_new(key, newvalue)

--- 384,397 ----
 assert not c.builtinflag

! Changing the value of an existing builtin:

 def reflect_bltin_change(self, 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.

***************
*** 400,404 ****
 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 
 (e.g. to increase security) in a way that makes these new
 copies override the previous ones in all modules ?
--- 401,405 ----
 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
 (e.g. to increase security) in a way that makes these new
 copies override the previous ones in all modules ?
***************
*** 418,422 ****

 A. The module's celldict would have a cell with a NULL objptr for
! that key.

 Q. What would the C code for LOAD_GLOBAL_CELL look like?
--- 419,427 ----

 A. The module's celldict would have a cell with a NULL objptr for
! 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,458 ****
--- 460,475 ----
 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