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

[Fred L. Drake]

Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv2359

Modified Files:
	pep-0205.txt 
Log Message:

Added text describing the two distinct aspects of any weak reference
implementation, with pros/cons for different options.


Index: pep-0205.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0205.txt,v
retrieving revision 1.11
retrieving revision 1.12
diff -C2 -r1.11 -r1.12
*** pep-0205.txt	2001/01/31 20:48:46	1.11
--- pep-0205.txt	2001/02/26 19:04:00	1.12
***************
*** 68,71 ****
--- 68,129 ----
  
  
+ Aspects of the Solution Space
+ 
+     There are two distinct aspects to the weak references problem:
+ 
+         - Invalidation of weak references
+         - Presentation of weak references to Python code
+ 
+     Invalidation:
+ 
+     Past approaches to weak reference invalidation have often hinged
+     on storing a strong reference and being able to examine all the
+     instances of weak reference objects, and invalidating them when
+     the reference count of their referent goes to one (indicating that
+     the reference stored by the weak reference is the last remaining
+     reference).  This has the advantage that the memory management
+     machinery in Python need not change, and that any type can be
+     weakly referenced.
+ 
+     The disadvantage of this approach to invalidation is that it
+     assumes that the management of the weak references is called
+     sufficiently frequently that weakly-referenced objects are noticed
+     within a reasonably short time frame; since this means a scan over
+     some data structure to invalidate references, an operation which
+     is O(N) on the number of weakly referenced objects, this is not
+     effectively amortized for any single object which is weakly
+     referenced.  This also assumes that the application is calling
+     into code which handles weakly-referenced objects with some
+     frequency, which makes weak-references less attractive for library
+     code.
+ 
+     An alternate approach to invalidation is that the de-allocation
+     code to be aware of the possibility of weak references and make a
+     specific call into the weak-reference management code to all
+     invalidation whenever an object is deallocated.  This requires a
+     change in the tp_dealloc handler for weakly-referencable objects;
+     an additional call is needed at the "top" of the handler for
+     objects which support weak-referencing, and an efficient way to
+     map from an object to a chain of weak references for that object
+     is needed as well.
+ 
+     Presentation:
+ 
+     Two ways that weak references are presented to the Python layer
+     have been as explicit reference objects upon which some operation
+     is required in order to retrieve a usable reference to the
+     underlying object, and proxy objects which masquerade as the
+     original objects as much as possible.
+ 
+     Reference objects are easy to work with when some additional layer
+     of object managemenet is being added in Python; references can be
+     checked for liveness explicitly, without having to invoke
+     operations on the referents and catching some special exception
+     raised when an invalid weak reference is used.
+ 
+     However, a number of users favor the proxy appoach simply because
+     the weak reference looks so much like the original object.
+ 
+ 
  Proposed Solution
  
***************
*** 109,114 ****
  
      The callbacks registered with weak references must accept a single
!     parameter, which will be the weakly referenced object itself.  The
!     object cannot be resurrected in the callback.
  
  
--- 167,173 ----
  
      The callbacks registered with weak references must accept a single
!     parameter, which will be the weak reference or proxy object
!     itself.  The object cannot be accessed or resurrected in the
!     callback.
  
  
***************
*** 141,148 ****
      dictionaries.  Whether it should include strings, buffers, lists,
      files, or sockets is debatable.
- 
-     There is a preliminary patch on SourceForge:
  
!     http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470
  
  
--- 200,206 ----
      dictionaries.  Whether it should include strings, buffers, lists,
      files, or sockets is debatable.
  
!     The implementation has already been added to the Python CVS
!     repository.