On Mon, Feb 21, 2022 at 12:24 PM Mark Dickinson <dicki...@gmail.com> wrote:

> e.g., It Would Be Nice If `-1 * complex(inf, 0.0)` gave `complex(-inf,
> -0.0)` instead of the current result of `complex(-inf, nan)`. But the price
> in added complexity - both conceptual complexity and implementation
> complexity - seems too high.
>

There are some heterogeneous binary operations implemented already. For
example 10**400 < float('inf') correctly returns True even though there's
no type in Python to which both values could be losslessly coerced to
perform that comparison.

I don't think adding a few more cases like that implies an obligation to
fix every case. It's a "perfect is the enemy of the good" situation.

I disagree with your notion of conceptual complexity. The conceptually
simplest thing to do is to perform the requested operation exactly and then
round if necessary. Only practical difficulties prevent that from happening
in all cases. It's not conceptually simple to convert int to float and
float to complex blindly regardless of the consequences. C99 gets complex *
real multiplication right, despite C being the poster child for numeric
promotions, and so does C++. It isn't hard to get it right, and programmers
would be happier if Python got it right. Programmers don't expect or want
consistent promotion to complex even when it breaks things.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5IOGT4XDKK2346C75QTFCU2SCTX4G373/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to