Message92197
The trunk patch is also unacceptable in its current form:
1. there are no docs or tests
2. keyval, start, step and end should have type long, not type int
(as Antoine already mentioned)
3. the expression ((keyval - start) % step) can overflow, leading to
undefined behaviour (e.g., wrong results, segfaults, strange
effects from gcc optimizations that assume no overflow). For
example, with the patch, on Linux/x86-64, I get:
>>> x = xrange(-2000000000, 2000000000, 5)
>>> 1000000000 in x
False
This should be relatively easy to fix: e.g., if you already
know that step > 0 and start <= keyval and keyval < stop, then
'(unsigned long)keyval - (unsigned long)start' is safe from
overflow.
4. the containment check only works for ints: with the patch, I get:
>>> x = xrange(10)
>>> 4 in x
True
>>> 4L in x
False
>>> 4.0 in x
False
but without the patch applied, all these return True. It's possible
that it's worth special-casing integer inputs for the sake of
speed, but I don't think the behaviour should change like this for
other types. |
|
Date |
User |
Action |
Args |
2009-09-03 10:03:18 | mark.dickinson | set | recipients:
+ mark.dickinson, rhettinger, belopolsky, pitrou, stargaming, hpesoj |
2009-09-03 10:03:18 | mark.dickinson | set | messageid: <1251972198.65.0.0140565392518.issue1766304@psf.upfronthosting.co.za> |
2009-09-03 10:03:16 | mark.dickinson | link | issue1766304 messages |
2009-09-03 10:03:15 | mark.dickinson | create | |
|