[Python-ideas] weakrefs

[stoneleaf]

On May 18, 9:38 am, Masklinn wrote:
> 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?

Indeed, that is the current bahavior.

> 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.

Because, since I had only been using CPython, I was able to count on
records that had gone out of scope disappearing along with their
_temporary_ changes.  If I get that same record back the next time I
loop
through the table -- well, then the changes weren't temporary, were
they?

>> 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.

And that's exactly the problem -- I don't want to see the
modifications the
second time 'round, and if I can't count on weakrefs invalidating as
soon as
the strong refs are gone I'll have to completely rethink how I handle
records
from the table.

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

Indeed -- I hadn't realized that I was until somebody using PyPy
noticed the
problem.

~Ethan~