Neil Schemenauer wrote: > > While working on the implementation of PEP 208, I discovered that > __coerce__ has some surprising properties. Initially I > implemented __coerce__ so that the numberic operation currently > being performed was called on the values returned by __coerce__. > This caused test_class to blow up due to code like this: > > class Test: > def __coerce__(self, other): > return (self, other) > > The 2.0 "solves" this by not calling __coerce__ again if the > objects returned by __coerce__ are instances. This has the > effect of making code like: > > class A: > def __coerce__(self, other): > return B(), other > > class B: > def __coerce__(self, other): > return 1, other > > A() + 1 > > fail to work in the expected way. The question is: how should > __coerce__ work? One option is to leave it work the way it does > in 2.0. Alternatively, I could change it so that if coerce > returns (self, *) then __coerce__ is not called again. +0 -- the idea behind the PEP 208 is to get rid off the centralized coercion mechanism, so fixing it to allow yet more obscure variants should be carefully considered. I see __coerce__ et al. as old style mechanisms -- operator methods have much more information available to do the right thing than the single bottelneck __coerce__. -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
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