range(2.9); coercions

[Tim Peters]

[John Machin]
> Does it concern anyone that range(2.9) *silently* returns [0, 1]?

Yes.  In particular, it concerns Guido, but there's no obvious way to fix it
(in general) now without breaking tons of code.

> ...
> However my real concern is not with the behaviour of range() itself,
> but with the *general* mechanism by which it gets that answer -- this
> mechanism would have been used by a large proportion of all the C
> extension modules ever written.

Bingo.

> Unless the birds ate my breadcrumbs while I was stumbling around the
> source for Python 2.1, what happens is this: the range()
> implementation calls PyArg_ParseTuple, saying that it expects "i"
> (integer) argument(s). This is however interpreted to include any
> instance of a type that has an nb_int slot, or a class that has an
> __int__() method.
>
> So 2.9 is a float, the float type supplies an nb_int slot, and
> int(2.9) -> 2 and so 2 is used as the open upper bound.

That's the problem.  nb_int doesn't distinguish the "I'm explicitly and
intentionally coercing away information" role from the "I'm sure this really
is an integer, but that it's inconviently in a floating-point format, so
just change representations" role.

You didn't get any other response to your note because it's a *real* problem
<wink>.

and-possibly-unsolvable-in-practice-if-not-in-theory-ly y'rs  - tim