On 11/4/2010 12:42 PM, Shashank Singh wrote:
Are there any promises made with regard to final state of the underlying
sequence that islice slices?
The one you quote below.
for example consider this
>>> from itertools import *
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
51
When posting code and result, it is always a good idea to include
version. It is even more important when reporting a (possible) bug,
which might have been fixed already. As it turns out, I get the same
behavior above and below with 3.1.2.
Now, the doc [1] says "If /stop/ is None, then iteration continues until
the iterator is exhausted, if at all; otherwise, it stops at the
specified position".
With a step greater than 1, 'specified position' is ambiguous. Any stop
value in [2,51] gives the same result. One could argue that the
effective stop value is either last returned + step as above does, or
last returned + 1 as Python version does.
It clearly is not stopping at stop (3).
Further, the doc gives an example of how this is *equivalent* to a
generator defined in the same section. It turns out, these two are not
exactly the
same if the side-effect of the code is considered on the underlying
sequence.
Redefining islice using the generator function defined in the doc gives
different (and from one pov, expected) result
>>> def islice(iterable, *args):
... # islice('ABCDEFG', 2) --> A B
...
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
2
While "fixing" this should be rather easy in terms of the change in code
required it might break any code depending
on this seemingly incorrect behavior.
[1]. http://docs.python.org/library/itertools.html#itertools.islice
If you file a bug report, please give the link.
If you do not want to, say so and I will.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
