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).

[Guido]
> Good point.  What does Scheme do?

[Tim Hochberg]
> Floor, ceiling, truncate and round all return integers.

Careful:  that (integer? x) returns true in Scheme does not imply that x "is
an integer" in Python's current sense (which has mostly to do with storage
format).  The std actually says (about floor & friends):

    the procedures listed below will always return an exact integer
    result provided all their arguments are exact integers and the
    mathematically expected result is representable as an exact
    integer within the implementation

and even that last part doesn't mean "stored in an integer format", while
there's an escape clause if floor (& friends) can't represent the *value*
"as an exact integer" (but what that means under the covers is
undiscoverable:  Scheme says and reveals nothing about internal
representations.).

> It seems that it wouldn't really be possible to have // do that
> consistently without PEP 237 though.

IMO, so long as we've got internal numeric representations on the brain,
Scheme's model makes little sense -- the point of Scheme's model was to get
away from representations and move toward abstract mathematical values.

That said, you may get to the same result in the end in this case anyway,
thanks to the contagiousness of inexactness (but not of *type*!):

> (integer? (floor (/ 20. 2)))
#t
> (exact? (floor (/ 20. 2)))
#f
>

So 20.//2 is not usable as a sequence index in Scheme, despite that "it's an
integer" (as Scheme means "an integer").  Python can get to the same place
in the end, but the terminological battle on the way there is going to be
excruciating.