Final state of underlying sequence in islice

[Terry Reedy]

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