[Python-checkins] CVS: python/nondist/peps pep-0205.txt,1.4,1.5
Fred L. Drake
python-dev@python.org
Fri, 17 Nov 2000 14:54:49 -0800
Update of /cvsroot/python/python/nondist/peps
In directory slayer.i.sourceforge.net:/tmp/cvs-serv27802
Modified Files:
pep-0205.txt
Log Message:
Updated information on Dianne Hackborn's old vref proposal. A copy of
her original proposal has been included as an appendix, since it is hard
to get since DejaNews lost their old archives.
Index: pep-0205.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0205.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -r1.4 -r1.5
*** pep-0205.txt 2000/11/08 06:47:05 1.4
--- pep-0205.txt 2000/11/17 22:54:45 1.5
***************
*** 104,119 ****
Previous Weak Reference Work in Python
! Diane Hackborn's vref proposal. 'vref' objects were very similar
! to java.lang.ref.WeakReference objects, except there was no
! equivalent to the invalidation queues. Implementing a "weak
! dictionary" would be just as difficult as using only weak
! references (without the invalidation queue) in Java. Information
! on this has disappeared from the Web. Original discussion
! occurred in the comp.lang.python newsgroup; a good archive of that
! may turn up something more.
- Dianne doesn't have any record of her proposal, and doesn't recall
- doing an implementation.
-
Marc-André Lemburg's mx.Proxy package. These Web pages appear to
be unavailable at the moment.
--- 104,116 ----
Previous Weak Reference Work in Python
! Dianne Hackborn's proposed something called "virtual references".
! 'vref' objects were very similar to java.lang.ref.WeakReference
! objects, except there was no equivalent to the invalidation
! queues. Implementing a "weak dictionary" would be just as
! difficult as using only weak references (without the invalidation
! queue) in Java. Information on this has disappeared from the Web.
! Original discussion occurred in the comp.lang.python newsgroup; a
! good archive of that may turn up something more.
Marc-André Lemburg's mx.Proxy package. These Web pages appear to
be unavailable at the moment.
***************
*** 128,131 ****
--- 125,132 ----
http://www.handshake.de/~dieter/weakdict.html
+ PyWeakReference by Alex Shindich:
+
+ http://sourceforge.net/projects/pyweakreference/
+
Possible Applications
***************
*** 133,137 ****
PyGTK+ bindings?
! Tkinter?
DOM trees?
--- 134,143 ----
PyGTK+ bindings?
! Tkinter -- could avoid circular references by using weak
! references from widgets to their parents. Objects won't be
! discarded any sooner in the typical case, but there won't be so
! much dependence on the programmer calling .destroy() before
! releasing a reference. This would mostly benefit long-running
! applications.
DOM trees?
***************
*** 141,144 ****
--- 147,282 ----
XXX -- Not yet.
+
+
+ Appendix -- Dianne Hackborn's vref proposal (1995)
+
+ [This has been indented and paragraphs reflowed, but there have be
+ no content changes. --Fred]
+
+ Proposal: Virtual References
+
+ In an attempt to partly address the recurring discussion
+ concerning reference counting vs. garbage collection, I would like
+ to propose an extension to Python which should help in the
+ creation of "well structured" cyclic graphs. In particular, it
+ should allow at least trees with parent back-pointers and
+ doubly-linked lists to be created without worry about cycles.
+
+ The basic mechanism I'd like to propose is that of a "virtual
+ reference," or a "vref" from here on out. A vref is essentially a
+ handle on an object that does not increment the object's reference
+ count. This means that holding a vref on an object will not keep
+ the object from being destroyed. This would allow the Python
+ programmer, for example, to create the aforementioned tree
+ structure tree structure, which is automatically destroyed when it
+ is no longer in use -- by making all of the parent back-references
+ into vrefs, they no longer create reference cycles which keep the
+ tree from being destroyed.
+
+ In order to implement this mechanism, the Python core must ensure
+ that no -real- pointers are ever left referencing objects that no
+ longer exist. The implementation I would like to propose involves
+ two basic additions to the current Python system:
+
+ 1. A new "vref" type, through which the Python programmer creates
+ and manipulates virtual references. Internally, it is
+ basically a C-level Python object with a pointer to the Python
+ object it is a reference to. Unlike all other Python code,
+ however, it does not change the reference count of this object.
+ In addition, it includes two pointers to implement a
+ doubly-linked list, which is used below.
+
+ 2. The addition of a new field to the basic Python object
+ [PyObject_Head in object.h], which is either NULL, or points to
+ the head of a list of all vref objects that reference it. When
+ a vref object attaches itself to another object, it adds itself
+ to this linked list. Then, if an object with any vrefs on it
+ is deallocated, it may walk this list and ensure that all of
+ the vrefs on it point to some safe value, e.g. Nothing.
+
+
+ This implementation should hopefully have a minimal impact on the
+ current Python core -- when no vrefs exist, it should only add one
+ pointer to all objects, and a check for a NULL pointer every time
+ an object is deallocated.
+
+ Back at the Python language level, I have considered two possible
+ semantics for the vref object --
+
+ ==> Pointer semantics:
+
+ In this model, a vref behaves essentially like a Python-level
+ pointer; the Python program must explicitly dereference the vref
+ to manipulate the actual object it references.
+
+ An example vref module using this model could include the
+ function "new"; When used as 'MyVref = vref.new(MyObject)', it
+ returns a new vref object such that that MyVref.object ==
+ MyObject. MyVref.object would then change to Nothing if
+ MyObject is ever deallocated.
+
+ For a concrete example, we may introduce some new C-style syntax:
+
+ & -- unary operator, creates a vref on an object, same as vref.new().
+ * -- unary operator, dereference a vref, same as VrefObject.object.
+
+ We can then define:
+
+ 1. type(&MyObject) == vref.VrefType
+ 2. *(&MyObject) == MyObject
+ 3. (*(&MyObject)).attr == MyObject.attr
+ 4. &&MyObject == Nothing
+ 5. *MyObject -> exception
+
+ Rule #4 is subtle, but comes about because we have made a vref
+ to (a vref with no real references). Thus the outer vref is
+ cleared to Nothing when the inner one inevitably disappears.
+
+ ==> Proxy semantics:
+
+ In this model, the Python programmer manipulates vref objects
+ just as if she were manipulating the object it is a reference
+ of. This is accomplished by implementing the vref so that all
+ operations on it are redirected to its referenced object. With
+ this model, the dereference operator (*) no longer makes sense;
+ instead, we have only the reference operator (&), and define:
+
+ 1. type(&MyObject) == type(MyObject)
+ 2. &MyObject == MyObject
+ 3. (&MyObject).attr == MyObject.attr
+ 4. &&MyObject == MyObject
+
+ Again, rule #4 is important -- here, the outer vref is in fact a
+ reference to the original object, and -not- the inner vref.
+ This is because all operations applied to a vref actually apply
+ to its object, so that creating a vref of a vref actually
+ results in creating a vref of the latter's object.
+
+ The first, pointer semantics, has the advantage that it would be
+ very easy to implement; the vref type is extremely simple,
+ requiring at minimum a single attribute, object, and a function to
+ create a reference.
+
+ However, I really like the proxy semantics. Not only does it put
+ less of a burden on the Python programmer, but it allows you to do
+ nice things like use a vref anywhere you would use the actual
+ object. Unfortunately, it would probably an extreme pain, if not
+ practically impossible, to implement in the current Python
+ implementation. I do have some thoughts, though, on how to do
+ this, if it seems interesting; one possibility is to introduce new
+ type-checking functions which handle the vref. This would
+ hopefully older C modules which don't expect vrefs to simply
+ return a type error, until they can be fixed.
+
+ Finally, there are some other additional capabilities that this
+ system could provide. One that seems particularily interesting to
+ me involves allowing the Python programmer to add "destructor"
+ function to a vref -- this Python function would be called
+ immediately prior to the referenced object being deallocated,
+ allowing a Python program to invisibly attach itself to another
+ object and watch for it to disappear. This seems neat, though I
+ haven't actually come up with any practical uses for it, yet... :)
+
+ -- Dianne