[Python-Dev] -Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220)

[Tim Peters]

[Guido]
> + + A new command line option, -D<arg>, is added to control run-time
> +   warnings for the use of classic division.
> ...
> +   Using -Dwarn issues a run-time warning about all uses of classic
> +   division for int, long, float and complex arguments.

I'm unclear on why we warn about classic division when a float or complex is
involved:

C:\Code\python\PCbuild>python -Dwarn
Python 2.2a2+ (#22, Aug 31 2001, 14:36:57) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 2./3.
__main__:1: DeprecationWarning: classic float division
0.66666666666666663
>>>

Given that this is going to return the same result even in Python 3.0, what
is it warning me about?  That is, as an end user, I'm being warned about
behavior I can't do anything about, and behavior that Python isn't going to
change anyway.


Different issue:  I would like to add OverflowError when coercion of long to
float yields a senseless result.  PEP 238 mentions this as a possibility,
and

>>> from __future__ import division
>>> x = 1L << 3000
>>> x/(2*x)
-1.#IND
>>>

really sucks.  For that matter,

>>> float(1L << 3000)
1.#INF
>>>

has always sucked; future division just makes it suck harder <wink>.

Any objections to raising OverflowError here?

Note this is a bit painful for a bogus reason:  PyFloat_AsDouble returns a
double, and nothing in the codebase now checks it for a -1.0 error return
(despite that it can already produce one).  So half the effort would be
repairing code currently ignoring the possibility of error.


Third issue:  I don't see a *good* reason for the future-division

    x/(2*x)

above not to return 0.5.  long_true_divide could be made smart enough to do
that (more generally, to return a good float approximation whenever the true
result is representable as a float).