[Python-ideas] weakrefs

[Michael Foord]

On 19 May 2012 03:54, stoneleaf <ethan at stoneleaf.us> wrote:

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


So you're taking a *dependence* on the reference counting garbage
collection of the CPython implementation, and when that doesn't work for
you with other implementations trying to force the same semantics on them.
Your proposal can't reasonably be implemented by other implementations as
working out whether there are any references to an object is an expensive
operation.

A much better technique would be for you to use explicit
life-cycle-management (like the with statement) for your objects.

Michael


>
> >> 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~
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 

http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120519/e5f4f806/attachment.html>