range(2.9); coercions

[John Machin]

"Tim Peters" <tim.one at home.com> wrote in message news:<mailman.996729123.19689.python-list at python.org>...
> [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.

I hope this doesn't start another episode of "Guido Agonistes versus
the Philistines" :-)

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

Possible mitigation or damage control:

(a) Documentation: There doesn't seem to be any documentation of (1)
the exact behaviour of the "i" format (2) that this behaviour is
regarded as inappropriate by the righteous -- there's certainly no
mention of it in the vicinity of the PyArg_ParseTuple docs.

(b) Provision of better alternatives for writers of extension modules:
For example, a format type of "I" which strictly requires an int type
(or at least no loss of information), not something coercible to int,
as does the "i" format.

Then there could be a bit of a crusade to encourage "I" and deprecate
"i".

Just my int(0.02) dollars' worth ...