> Shashank Singh <shashank.sunny.si...@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 -- http://mail.python.org/mailman/listinfo/python-list
