Final state of underlying sequence in islice
tjreedy at udel.edu
Sat Nov 6 07:07:18 CET 2010
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
More information about the Python-list