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

[Tim Peters]

[Terry Reedy]
> If I write def(seq, n, k): return seq[3*n//k] and a call receives
> n=20.0 instead of 20, it would accord with the polymorphic rationale
> for new / and // to go ahead and return the item intended.  Or perhaps
> floored numbers should be marked as exact (if the marking is
> independent of type).

Type-based "exact vs inexact" schemes sound better than they're likely to
work, IMO.

Example:

    x = 6.02e23  # reading as floating double, and presumably inexact
    y = x // 1   # exact?!

y == x after those, but what sense would it make for y to be exact then?

Example:

    y = w - w

Whether w is exact or inexact, it's certain that y is exactly 0 after that.
So the rule that "inexactness is always contagious" makes no sense (and,
indeed, the Scheme std leaves so many holes to accommodate cases "like this
one" that there's no guessing what will happen).

Example:

    x = math.sqrt(4)  # if inexact result, why?!

That is, even in float-land, sqrt(4) is just as exact as 4 is.

Scheme bit one part of this bullet so-far unchewed here:  the idea that
floats are always inexact and ints always exact makes no sense either (I
worked 2 hours today and exchanged 1e3 pennies for a ten-dollar bill); so
Scheme has literal notations allowing to explictly say that an integer
literal is inexact, and that a floating literal is exact, when appropriate.

exactness-is-neither-a-type-nor-an-operation-property-ly y'rs  - tim