proposed language change to int/int==float (was: PEP0238 lament)

[Guido van Rossum]

David Bolen <db3l at fitlinxx.com> writes:

> Guido van Rossum <guido at python.org> writes:
> 
> > "Bjorn Pettersen" <BPettersen at NAREX.com> writes:
> > 
> > > I think perhaps an equally interesting example is something like:
> > > 
> > >   2L**128/2
> > > 
> > > which currently gives an exact result, but under the proposed new
> > > semantics would give an approximation...
> > 
> > Have you read the PEP?  The PEP only returns a float if the int result
> > would yield a remainder.
> 
> Does it?  While returning an integral value in the above case,
> wouldn't it would in fact be a float data type (barring the addition
> of rationals), as per:
> 
>     (from PEP238)
> 
>     "The type of a/b will be either a float or a rational, depending on
>     other PEPs[2, 3]. However, the result will be integral in all case
>     the division has no remainder."
> 
> And given that, what happens if float can't represent the resulting
> precision necessary?
> 
> Of course, this is only true later when this is the default, right?
> Until then, the "future" implementation is an addition of 0.0 to the
> divisor, so the result would definitely be float, and not necessarily
> integral.
> 
> Unless you meant something other than the data type involved by
> "returns a float".

The PEP is currently contradictory and incomplete.  The "future
division" operator (generated by x/y when in the scope of a future
division statement) will return either a rational or a float --
obviously it can't return a rational until they have been made part of
the language (which may or may not ever happen).  Since 2.2 won't have
rationals, it will return a float even for 2L**128/2 -- but only when
you use a future division statement, and in that case you get what you
ask for.

The current patch on SF adds 0.0 but that's not what it will do once
2.2 is released.

--Guido van Rossum (home page: http://www.python.org/~guido/)