Final state of underlying sequence in islice

[Terry Reedy]

On 11/5/2010 4:51 PM, Raymond Hettinger wrote:
> On Nov 5, 1:05 pm, Terry Reedy<tjre... at udel.edu>  wrote:
>>> Currently, there are no promises or guarantees about the final state
>>> of the iterator.
>>
>> I interpret the current doc statement as a promise that becomes
>> ambiguous when step>  1.
>
> You may have missed my point.

And you may have missed mine ;-)

> I wrote the tools, the docs, and the tests.

As I know. Thank you again.

> If you interpret a "promise" in text, I can assure you it was not
> intended.  The behavior *is* undefined because I never defined it.
> I'm happy to clarify the docs to make that explicit.

Let me be clearer. Looking at that sentence *before* your initial answer 
to the OP, I interpreted (past tense) it as I said above.

> Or I can alter the implementation a bit to make a guarantee
> if it looks like there is a good reason to do so.

One reason is that it is too easy for someone experimenting with islice 
to write a call that will run for a l  o  n  g time. I had to cancel a 
couple of times when I was investigating the C versus Python versions 
and islice versus range behavior with large numbers (for the other 
islice issue on the tracker).  In other words, the current 
implementation is a bit of a trap, especially since the C version runs 
for as long as possible while the Python version as short as possible.

-- 
Terry Jan Reedy