On Sun, Mar 4, 2018 at 3:19 AM, Richard Damon <rich...@damon-family.org> wrote: > 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.
I'm not sure what __unref__ gives you that __del__ doesn't, aside from mandating that every Python implementation from here to eternity MUST use reference counting. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
