David Abrahams: > What's the point of the proxy? You never use it for anything. I guess > you must've meant: > python_function(proxy) > above. <blush> Nice catch. > Hum. In Boost.Python the default is to copy the C++ object when > passing it to a Python callback, though it's possible for the user > to explicitly say "just build a Python object around a reference to > the C++ object -- Python code beware of lifetime issues". I guess I > like your idea, though, as a safer alternative for non-copyable or > for very expensive-to-copy C++ objects. DOMs, the data structures in question, can be obscenely expensive to copy. And I firmly believe that Python code should never be able to cause a crash. [nice demonstration deleted] > How does this differ from what's happening for you? When you created the bound method p.append, you caused the reference count of p to be increased. In my case, since Python is not capable of altering the lifetime of p (it's dead with the C library says that it is dead), this is a bad thing. So I proxy the bound methods and kill them when p dies. > Hmm, it kinda seems like you want to prune some of them before the > user's done with them. I actually presented two different desires at once and know I'm paying the price. There are two reasons that I might want to delete a proxied object: 1. Its lifetime is over and I don't want anyone to access it 2. There are no proxy objects that refer to it, making it inaccessible (since I hold the only actual reference) Reason #1 is why I could like builtin methods to support weakrefs. Reason #2 is why I would like a callback when the last weakref dies. > Don't users expect objects to stay alive when they hold references? Probably. But that is not always an option. Cheers, Brian
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4