[Python-3000] weakrefs of bound methods

Guido van Rossum guido at python.org
Fri Feb 15 22:20:03 CET 2008


On Fri, Feb 15, 2008 at 12:52 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 11:41 AM 2/15/2008 -0800, Guido van Rossum wrote:
>  >On Fri, Feb 15, 2008 at 10:26 AM, Phillip J. Eby
>  ><pje at telecommunity.com> wrote:
>
> > >  I've never actually encountered a usecase for keeping a standard
>  > >  weakref to a standard bound method, though.  It's pretty useless,
>  > >  because bound methods are nearly always immediately disposed of, and
>  > >  there's no logical place (or reason) to store them.  So, Nick's query
>  > >  is (in effect), can we either:
>  > >
>  > >  1. make ref(method) create a "weak method" instead, or
>  > >
>  > >  2. make ref(method) an error instead of useless behavior that gives
>  > >  you the illusion of working code
>  >
>  >#2 is easily implemented (just remove the machinery to support weak
>  >refs from the bound method object) but the question is, will it break
>  >anybody's code -- and if so, do we care enough to break it? (In Py3k,
>  >that is.)
>
>  It's hard to imagine what could be using it, but I guess it's possible.
>
>
>
>  >#1 isn't so easy in terms of how you'd implement it -- I don't think
>  >the weakref.ref() call currently has a way to customize what kind of
>  >thing you get back. I'd be open for a patch containing working code
>  >that can be generalized to other cases.
>
>  Well, one could allow for a __weaken__ method that would be called if
>  present, instead of the default constructor.  The part I'm not
>  immediately sure of is where to call it *from*, so that you can still
>  subclass weakref.ref and not end up in a strange delegation loop.  I
>  guess you could call it if and only if weakref.ref.__new__ was passed
>  weakref.ref as the class to construct.

I think str() does this.

But maybe given how rare the use case is, it would be easier to just
create a custom class in weakref.py that does what Nick requested.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-3000 mailing list