[Python-Dev] Issue 643841: Including a new-style proxy base class in 2.6/3.0 (original) (raw)

Michael Foord fuzzyman at voidspace.org.uk
Tue May 27 15:09:28 CEST 2008

Nick Coghlan wrote:

Armin Ronacher wrote:

Hi,

Nick Coghlan <ncoghlan gmail.com> 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)

Couldn't in place operations wrap the return value with a proxy?

Michael Foord

- 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 testtypetools.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.

More information about the Python-Dev mailing list