[Python-ideas] weakrefs

[Masklinn]

On 2012-05-18, at 18:08 , stoneleaf wrote:
> 
> My dbf module provides direct access to dbf files.  A retrieved record
> is
> a singleton object, and allows temporary changes that are not written
> to
> disk.  Whether those changes are seen by the next incarnation depends
> on
> (I had thought) whether or not the record with the unwritten changes
> has
> gone out of scope.

If a record is a singleton, that singleton-ification would be handled
through weakrefs would it not?

In that case, until the GC is triggered (and the weakref is
invalidated), you will keep getting your initial singleton and there
will be no "next record", I fail to see why that would be an issue.


> I see two questions that determine whether this change should be made:
> 
>  1) How difficult it would be for the non-ref counting
> implementations
>     to implement
> 

Pretty much impossible I'd expect, the weakrefs can only be broken on GC
runs (at object deallocation) and that is generally non-deterministic
without specifying precisely which type of GC implementation is used.
You'd need a fully deterministic deallocation model to ensure a weakref
is broken as soon as the corresponding object has no outstanding strong
(and soft, in some VMs like the JVM) reference.

>  2) Whether it's appropriate to have objects be changed, but not
> saved,
>     and then discarded when the strong references are gone so the
> next
>     incarnation doesn't see the changes, even if the object hasn't
> been
>     destroyed yet.

If your saves are synchronized with the weakref being broken (the object
being *effectively* collected) and the singleton behavior is as well,
there will be no difference, I'm not sure what the issue would be, you
might just have a second change cycle using the same unsaved (but still
modified) object.

Although frankly speaking such reliance on non-deterministic events would
scare the shit out of me.