<p dir="ltr">You can check the .image attribute, which exists on floats too (and ints).</p>
<p dir="ltr">--Guido van Rossum (sent from Android phone)</p>
<div class="gmail_quote">On Oct 20, 2012 6:54 PM, "Steven D'Aprano" <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 21/10/12 06:28, Tres Seaver wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
On 10/19/2012 07:35 PM, Greg Ewing wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Antonio Cuni wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Traceback (most recent call last): File "<stdin>", line 1, in<br>
<module>  TypeError: __complex__ should return a complex object<br>
<br>
i.e., the complex constructor does not check that __complex__<br>
returns an actual complex, while the cmath functions do.<br>
</blockquote>
<br>
Looks to me like cmath is being excessively finicky here. Why<br>
shouldn't a float be usable in *any* context expecting a complex?<br>
</blockquote>
<br>
Exactly:  float is perfectly Liskov-substituable for complex;  only<br>
applications which do explicit type sniffing can tell the difference,<br>
which makes the sniffing bogus.<br>
</blockquote>
<br>
<br>
But float is not *numerically* substitutable for complex, which is why<br>
type-sniffing is not bogus at all. If you have an application which<br>
assumes numeric quantities represent real values, then you need to<br>
distinguish between real-valued and complex-valued arithmetic, and<br>
treating floats as implicitly complex is the wrong thing to do.<br>
<br>
Since most applications are based on real-values, implicit promotion to<br>
complex is in my opinion an anti-feature.<br>
<br>
Python 2.x legitimately distinguished between floats and complex, e.g.:<br>
<br>
py> (-100.0)**0.5<br>
Traceback (most recent call last):<br>
  File "<stdin>", line 1, in <module><br>
ValueError: negative number cannot be raised to a fractional power<br>
<br>
If you wanted a complex result, you can explicitly ask for one:<br>
<br>
py> (-100.0+0j)**0.5<br>
(6.123031769111886e-16+10j)<br>
<br>
<br>
I see that behaviour is changed in Python 3. Was this discussed before<br>
being changed? I see a single sample docstring buried in PEP 3141 that:<br>
<br>
"""a**b; should promote to float or complex when necessary."""<br>
<br>
but I can't find any discussion of the consequences of this for the<br>
majority of users who would be surprised by the unexpected appearance<br>
of a "j" inside their numbers.<br>
<br>
Nor is there any hint in the docs for pow and ** that they will promote<br>
floats to complex:<br>
<br>
<a href="http://docs.python.org/dev/library/functions.html#pow" target="_blank">http://docs.python.org/dev/<u></u>library/functions.html#pow</a><br>
<br>
<a href="http://docs.python.org/dev/library/stdtypes.html#numeric-types-int-float-complex" target="_blank">http://docs.python.org/dev/<u></u>library/stdtypes.html#numeric-<u></u>types-int-float-complex</a><br>
<br>
<br>
<br>
-- <br>
Steven<br>
______________________________<u></u>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/<u></u>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/guido%40python.org" target="_blank">http://mail.python.org/<u></u>mailman/options/python-dev/<u></u>guido%40python.org</a><br>
</blockquote></div>