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