Final state of underlying sequence in islice

[Raymond Hettinger]

>  Shashank Singh <shashank.sunny.si... at gmail.com> wrote:
>
> > Are there any promises made with regard to final state of the underlying
> > sequence that islice slices?

Currently, there are no promises or guarantees about the final state
of the iterator.

To the extent the pure Python version in the docs differs from the
CPython implementation in this regard, it is an accidental
implementation detail.

That being said, we could introduce some guarantees (earliest possible
stop point, latest possible stop point, or decide to leave it
undefined).  I'm curious about your use case, as it might guide the
decision.  Are there any useful invariants that might arise from one
choice or the other?

The case is question seems a bit rare (the stop argument indexes an
element before the iterator terminates, the step argument is more than
one, the stop argument is not at the start plus an exact multiple of
step, and you care about where the iterator is afterwards).  The
question is why you would have all of those conditions and not have
stop==start+n*step.

For regular slices, you seem to get useful invariants only when stop
falls along the natural boundaries:

  s[a:b:step] + s[b:c:step] == s[a:c:step]  # only when b == a+n*step

So, it's not obvious what the semantics should be when b != a+n*step.


Raymond