On 21/10/12 13:57, Nick Coghlan wrote:
On Sun, Oct 21, 2012 at 11:53 AM, Steven D'Aprano<st...@pearwood.info>  wrote:

Python 2.x legitimately distinguished between floats and complex, e.g.:

py>  (-100.0)**0.5

Traceback (most recent call last):
   File "<stdin>", line 1, in<module>
ValueError: negative number cannot be raised to a fractional power

If you wanted a complex result, you can explicitly ask for one:

py>  (-100.0+0j)**0.5
(6.123031769111886e-16+10j)


I see that behaviour is changed in Python 3. Was this discussed before
being changed? I see a single sample docstring buried in PEP 3141 that:

"""a**b; should promote to float or complex when necessary."""

but I can't find any discussion of the consequences of this for the
majority of users who would be surprised by the unexpected appearance
of a "j" inside their numbers.

PEP 3141 is indeed the driver for these changes, and it's based on the
Python 3.x numeric tower consisting of strict supersets: Complex>
Real>  Rational>  Integral

If an operation at one level of the tower produces a result in one of
the larger supersets, then *that's what it will do* rather than
throwing TypeError. int / int promoting to float is one example, as is
raising a negative number to a fractional power promoting to complex.

The general philosophy is described in
http://www.python.org/dev/peps/pep-3141/#implementing-the-arithmetic-operations

Yes, I've read that. But it seems to me that this change appears to have
been driven by type-purity (floats are Liskov-substituable for complex)
rather than practical considerations for people who may not know what
complex numbers are, or at best may have vague recollections of being
told about them in high school, and who now have to deal with the
unexpected appearance of complex numbers in calculations which previously
gave an exception.

When you're dealing with numbers that represent real quantities, getting
a complex result is nearly always an error condition. Better to get an
exception at the point that occurs, than somewhere distant when the number
gets fed to %f formatting, or worse, no error at all, just a silently
generating garbage results.



--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to