[Python-Dev] Anyone using weakrefs?

[Emile van Sebille]

Thanks!  That's cool.  I'd wondered if there was a way to re-swizzle in
objects if they still existed from the ID alone, and it looks like this can
do it.  I've got a process that takes up about 700Mb of my system's 512Mb
memory, and for testing runs about 5 1/2 hours.  It runs about 10 minutes on
the client's 2Gb system, even though their processor is 1/3 the speed.  I
never realized that thrashing could make such a difference.

At this point, it's in place and they've paid the price, but I'll start
playing with weak references to see if it improves my local test
performance.  I'm practicing one-man-shop XP ;-) and when the both of us get
into it, being able to do more than a single iteration per day would really
help.

--

Emile van Sebille
emile at fenx.com

---------
"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.985469191.25050.python-list at python.org...
> [Fred Drake]
> > Is anyone out there playing with the weak references support yet?
> > I'd *really* appreciate receiving a short snippet of non-contrived
> > code that makes use of weak references to use in the documentation.
>
> Alas, it's kinda like asking for a "short snippet" illustrating
coroutines:
> the need isn't apparent in tiny examples.
>
> Still, I've been happily playing w/ this little module:
>
> import weakref
> id2obj_dict = weakref.mapping()
>
> def remember(obj):
>     id2obj_dict[id(obj)] = obj
>
> def id2obj(id):
>     return id2obj_dict.get(id, None)
>
> In various introspective tools (like Cyclops.py), there's a need to keep
> track of "other peoples'" class instances.  Before weakrefs, it was
> impossible to do this without keeping the instances artificially alive.
Now
> I can pass arbitrary instances to remember() above, then just use their
ids
> internally.  This doesn't keep the objects alive, but id2obj() above can
> still get the objects back so long as they're still alive.
>
> I suppose I could work with weakrefs directly instead of indirecting
through
> id()s, but most code of this nature I have is already mucking w/ ids
anyway
> (ints are small, fast, cheap and make great dict keys themselves).
>
>