this may still be premature, but i see people misunderstood the purpose.
weakattrs are not likely to be used "externally", out of the scope of
the object.
they are just meant to provide an easy to use means for not holding cyclic
references between parents and children.
many graph-like structures, i.e., rpyc's node and proxies, are interconnected
in both ways, and weakattrs help to solve that: i don't want a proxy of a node
to keep the node alive.
weakmethods are used very similarly. nodes have a method called
"getmodule", that performs remote importing of modules. i expose these
modules as a namespace object, so you could do:
>>> mynode.modules.sys
or
>>> mynode.modules.xml.dom.minidom.parseString
instead of
>>> mynode.getmodule("xml.dom.minidom").parseString
here's a sketch:
def ModuleNamespace:
def __init__(self, importerfunc):
self.importerfunc = importerfunc
class Node:
def __init__(self, stream):
....
self.modules = ModuleNamespace(self.getmodule)
@ weakmethod
def getmodule(self, name):
....
i define this getmodule method as a *weakmethod*, so the mere existence
of the ModuleNamespace instance will not keep the node alive. when the
node loses all external references, the ModuleNamespace should just
"commit suicide", and allow the node to be reclaimed.
yes, you can do all of these with today's weakref, but it takes quite
a lot of hassle to manually set up weakproxies every time.
-tomer
On 9/29/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Alex Martelli]
>
> >I've had use cases for "weakrefs to boundmethods" (and there IS a
> >Cookbook recipe for them),
> >
> Weakmethods make some sense (though they raise the question of why bound
> methods are being kept when the underlying object is no longer in use --
> possibly as unintended side-effect of aggressive optimization).
>
> I'm more concerned about weakattr which hides the weak referencing from
> client code when it is usually the client that needs to know about the
> refcounts:
>
> n = SomeClass(x)
> obj.a = n
> del n # hmm, what happens now?
>
> If obj.a is a weakattr, then n get vaporized; otherwise, it lives.
>
> It is clearer and less error-prone to keep the responsibility with the
> caller:
>
> n = SomeClass(x)
> obj.a = weakref.proxy(n)
> del n # now, it is clear what happens
>
> The wiki-space example shows objects that directly assign a copy of self
> to an attribute of self. Even in that simplified, self-referential
> example, it is clear that correct functioning (when __del__ gets called)
> depends knowing whether or not assignments are creating references.
> Accordingly, the code would be better-off if the weak-referencing
> assignment was made explicit rather than hiding the weak-referencing
> wrapper in a descriptor.
>
>
>
> Raymond
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
