> [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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4