tim.one at home.com
Thu Aug 2 07:11:01 CEST 2001
> 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.
> 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
and-possibly-unsolvable-in-practice-if-not-in-theory-ly y'rs - tim
More information about the Python-list