-Dwarn, long->double overflow (was RE: [Python-checkins] CVS: python/dist/src/Misc NEWS,1.219,1.220)
[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).
participants (6)
-
bckfnnïĵ worldonline.dk
-
Fredrik Lundh
-
Greg Stein
-
Guido van Rossum
-
Thomas Wouters
-
Tim Peters