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.5067827e-06
Marked as misclassified No
Message-id <1234304587.24.0.0166894287074.issue3734@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2009-02-10 22:23:07mark.dickinsonsetrecipients: + mark.dickinson, ajaksu2, gumtree
2009-02-10 22:23:07mark.dickinsonsetmessageid: <1234304587.24.0.0166894287074.issue3734@psf.upfronthosting.co.za>
2009-02-10 22:23:05mark.dickinsonlinkissue3734 messages
2009-02-10 22:23:04mark.dickinsoncreate