On 11/5/2010 4:51 PM, Raymond Hettinger wrote:
On Nov 5, 1:05 pm, Terry Reedy<tjre...@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
--
http://mail.python.org/mailman/listinfo/python-list
