[Python-Dev] PEP 208 and __coerce__

[M.-A. Lemburg]

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/