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

[Guido van Rossum]

> [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/)