@grahamd
Well, I read the PEP for weakproxy and python doc on weakref library, and I got an impression that weakproxy is really like a weak pointer in C++: i can pass it around as it was a strong pointer, and get an exception if actual object has been deleted. Well, but I see now that it was wrong.

My use case

If you are familiar with kazoo library, then what I am making is similar to KazooClient object. See here, for example:
https://kazoo.readthedocs.org/en/latest/basic_usage.html#connection-handling
The typical usage for my object is like this:

zk = KazooClient(hosts='127.0.0.1:2181')
zk.start()
# user *MUST* call zk.stop() otherwise there is a leak

Now I think it's not user-friendly to require the call to zk.stop(). I prefer the call to stop() to be called automatically from destructor of zk object whenever it goes out of scope. However, the background thread which is created in zk.start() also holds reference to zk object, and so __del__ is never called, the thread is never stopped, and the leak occurs.

Of course, I can do this to solve the problem above:

class Wrapper(object):
  def __init__(self, *args, **kwargs):
    self.__obj = KazooClient(*args, **kwargs)
    self.__obj.start()
  def __getattr__(self, attr):
    return getattr(self.__obj, attr)
  def __del__(self):
    self.__obj.stop()


But even this doesn't quite solve the problem of callbacks. To have callbacks from KazooClient, they have to be stored in Wrapper object instead, and KazooClient has to be given weak references to some special Wrapper method, which will call the real callback. When KazooClient executes callback, it operates on a weakproxy, but as soon as it calls wrapper.method() the weakproxy is transformed to actual instance, and that complicates things.

It still works with current weakref implementation, but it would be simpler and more flexible if the weakproxy was working as I expected, as then I don't have to use unnatural calls: Class.method(proxy, ...) instead of just proxy.method(...).