On 3/3/18 9:03 AM, Ian Kelly wrote:
On Fri, Mar 2, 2018 at 9:57 PM, Gregory Ewing
<greg.ew...@canterbury.ac.nz> wrote:
Paul Rubin wrote:
So you want the programmer to put more head scratching into figuring out
which reference should be strong and which should be weak?
Also, sometimes weak references don't really solve the
problem, e.g. if you have a graph where you can't identify
any particular node as a "root" node, and you want the graph
to stay around as long as any of its nodes are referenced.
I offered two possible solutions for the graph problem elsewhere in this thread.
For the record I'm not in favor of the OP's proposal (although making
the different Python implementations more consistent in their garbage
collection semantics would not be a bad thing per se) but I am
somewhat mystified as to why people seem to think that weak refs are
difficult to use correctly.
As I think about this, and coming from a background where I have found
the ability to reliably use RAII useful in some cases, I can see some
merit to the proposal. One big issue is that since Python doesn't have
sub-function level lifetime scopes for locals, it is perhaps not quite
as useful in some cases.
One idea does come to mind though, would it be reasonable, and somewhat
Pythonic, for a class to define member functions like __ref__ and
__unref__ (or perhaps some other name) that if defined, would be called
every time a name was bound or unbound to an object? (the assignment to
a name should __ref__ the new value, then __unref__ the old to avoid
possible issues with rebinding an object to the last name it was bound
to). This would allow those (limited) objects that want to be destroyed
as soon as possible to do so, but most other objects wouldn't have any
significant overhead added (just a check for this method).
Objects with these methods would still be subject to being cleaned up
with garbage collection in the case they were kept alive via a cycle,
having the cycle just makes it so that you don't get the immediate
distruction.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list