Added text describing the two distinct aspects of any weak reference

implementation, with pros/cons for different options.

pep-0205.txt

@@ -67,6 +67,64 @@ Motivation
     since it does not appear to be available on the net.
 
 
+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
 
     Weak references should be able to point to any Python object that
@@ -108,8 +166,9 @@ Proposed Solution
     work, but always refer to the proxy and not the referent.
 
     The callbacks registered with weak references must accept a single
-    parameter, which will be the weakly referenced object itself.  The
+    parameter, which will be the weak reference or proxy object
-    object cannot be resurrected in the callback.
+    itself.  The object cannot be accessed or resurrected in the
+    callback.
 
 
 Implementation Strategy
@@ -141,9 +200,8 @@ Implementation Strategy
     dictionaries.  Whether it should include strings, buffers, lists,
     files, or sockets is debatable.
 
-    There is a preliminary patch on SourceForge:
+    The implementation has already been added to the Python CVS
-
+    repository.
-    http://sourceforge.net/patch/?func=detailpatch&patch_id=103203&group_id=5470
 
 
 Possible Applications