| msg72169 - (view) |
Author: Blair (gumtree) |
Date: 2008-08-29 22:39 |
| The following is quoted from the Python docs (ref/numeric_types): "Note: If the right operand's type is a subclass of the left operand's type and that subclass provides the reflected method for the operation, this method will be called before the left operand's non-reflected method. This behavior allows subclasses to override their ancestors' operations." My issue is that the built-in complex type does not respect this rule (see code below). Note that float can be subclassed using the method shown below and the rules are applied correctly. It seems that it is only a problem with complex. class xcomplex( complex ): def __new__(cls,*args,**kwargs): return complex.__new__(cls,*args,**kwargs) def __coerce__(self,other): t = complex.__coerce__(self,other) try: return (self,xcomplex(t[1])) except TypeError: return t def __add__(self,x): return xcomplex( complex.__add__(self,x) ) def __radd__(self,x): return xcomplex( complex.__radd__(self,x) ) print type(z + xz) # gives complex when xcomplex is required |
|
|
| msg81571 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-02-10 18:12 |
| Confirmed in trunk. Here's a copy-n-past'able testcase: class xcomplex( complex ): def __new__(cls,*args,**kwargs): return complex.__new__(cls,*args,**kwargs) def __coerce__(self,other): t = complex.__coerce__(self,other) try: return (self,xcomplex(t[1])) except TypeError: return t def __add__(self,x): return xcomplex( complex.__add__(self,x) ) def __radd__(self,x): return xcomplex( complex.__radd__(self,x) ) class xfloat(float): def __new__(cls,*args,**kwargs): return float.__new__(cls,*args,**kwargs) def __coerce__(self,other): t = float.__coerce__(self,other) try: return (self,float(t[1])) except TypeError: return t def __add__(self,x): return xfloat( float.__add__(self,x) ) def __radd__(self,x): return xfloat( float.__radd__(self,x) ) z = 1j xz = xcomplex(1j) f = 1.0 xf = xfloat(1.0) print type(z + xz) print type(f + xf) |
|
|
| msg81584 - (view) |
Author: Mark Dickinson (mark.dickinson) *  |
Date: 2009-02-10 19:21 |
| I'll take a look. |
|
|
| msg81609 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-02-10 22:23 |
| So there's a hint about what's happening here at the bottom of the section http://docs.python.org/reference/datamodel.html#id5 of the docs, where it says: """In the current implementation, the built-in numeric types int, long and float do not use coercion; the type complex however does use it. The difference can become apparent when subclassing these types. Over time, the type complex may be fixed to avoid coercion. [...]""" In the OPs example, when z + xz is evaluated, xz is (successfully) coerced to type complex, and then complex.__add__ is called to do the addition as usual. There's definitely (at least) a documentation bug here, given that at the same place as referenced above it says: """New-style classes (those derived from object) never invoke the __coerce__() method in response to a binary operator; the only time __coerce__() is invoked is when the built-in function coerce() is called.""" At the level of the C code, the practical difference between complex and (for example) float is that the float type has Py_TPFLAGS_CHECKTYPES set, and all arithmetic operations do their own conversions. The complex type doesn't set Py_TPFLAGS_CHECKTYPES, and so (contrary to the documentation) relies on complex_coerce to do any conversions. |
|
|
| msg81613 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-02-10 23:31 |
| I think this issue comes down to a doc fix, though I've opened issue 5211 for anyone who fancies having a go at removing coercion from the complex type. Here's a doc patch. |
|
|
| msg81614 - (view) |
Author: Blair (gumtree) |
Date: 2009-02-11 00:00 |
| While Mark Dickinson's patch fixes the documentation, it does not offer a solution to the original problem, which was rooted in a need to provide special behaviour based on the numeric types. I made the original posting because I hoped that this problem could be resolved. |
|
|
| msg81634 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-02-11 08:58 |
| [gumtree] > [...] does not offer > a solution to the original problem, which was rooted in a need to > provide special behaviour based on the numeric types. I made the > original posting because I hoped that this problem could be resolved. Please see issue 5211 for further discussion. |
|
|
| msg81902 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2009-02-13 10:45 |
| Applied doc patch in r69573. |
|
|