[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.
Sorry, I should have explained the intention. This warning is intended for perusal by a tool (yet to create) that reads the warnings and can automatically fix your code by inserting the proper future division statements and/or replace / by //. The tool parses the source looking for / operators. For each / it sees if it has corresponding warnings, and if so, if the warnings are consistent (only int/long or only float/complex), it does the right thing. If all / operators in a module have at least one warning, it assumes that it has full coverage, and it adds a future division statement to the module. If there are some / operators for which it doesn't have any warnings, it asks the user to create a better test case. For this, it needs to know about float and complex divisions as well.
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?
Sounds OK to me.
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).
Sure, but I also don't see a good reason to make this a priority. It's a "don't care" corner of the language to me. --Guido van Rossum (home page: http://www.python.org/~guido/)