Armin Ronacher wrote:
Hi,
Nick Coghlan
writes: What version are you using, and are your proxies correctly implementing all the __r*__ versions of the methods? The link to the ugly proxy is in the mail :-) And no, I'm currently not providing any __r*__ methods as I was too lazy to test on each call if the method that is proxied is providing an __rsomething__ or not, and if not come up with an ad-hoc implementation by calling __something__ and reversing the arguments passed.
I had another look - indeed, it is almost certainly the missing __r*__ methods which are causing problems for you when interacting with unproxied objects. The other differences between what you're doing and the proposed typetools.ProxyMixin are that: - ProxyMixin delegates the whole __getattribute__ operation to the target object so that descriptors work correctly (invoking object.__getattribute__ explicitly when it needs to retrieve the proxy object's _target attribute). - ProxyMixin correctly delegates in-place assignment operations via the __i*__ methods (note however that using in-place assignment will remove the proxy wrapper, just as it does for weakref.proxy) - ProxyMixin implicitly unwraps other ProxyMixin instances when it encounters them as an argument to an explicitly proxied operation - ProxyMixin doesn't support deprecated operations like __getslice__ or __methods__
While there are still some cases where types in the standard library raise TypeError directly instead of returning NotImplemented, they're generally pretty good about playing well with others (see the test_typetools.py file attached to the tracker item for #643841) I also think that the stdlib should mention NotImplemented with a big warning. I see countless classes raising TypeError()s if __add__ or something fails which seem to work alright as long as someone tries to __radd__ it.
Returning NotImplemented is already mentioned in the documentation for the binary special methods, but I agree that it could be made more obvious that explicitly raising a TypeError from these methods is almost certainly the wrong thing to do. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org