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

[Michael Foord]

Nick Coghlan wrote:
> Armin Ronacher wrote:
>> Hi,
>>
>> Nick Coghlan <ncoghlan <at> 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 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.
>