This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients ajaksu2, gumtree, mark.dickinson
Date 2009-02-10.22:23:04
SpamBayes Score 1.50678e-06
Marked as misclassified No
Message-id <>
So there's a hint about what's happening here at the bottom of the section

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 

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.
Date User Action Args
2009-02-10 22:23:07mark.dickinsonsetrecipients: + mark.dickinson, ajaksu2, gumtree
2009-02-10 22:23:07mark.dickinsonsetmessageid: <>
2009-02-10 22:23:05mark.dickinsonlinkissue3734 messages
2009-02-10 22:23:04mark.dickinsoncreate