Final state of underlying sequence in islice
python at rcn.com
Sat Nov 6 01:32:01 CET 2010
On Nov 5, 3:52 pm, Ian <ian.g.ke... at gmail.com> wrote:
> On Nov 5, 2:51 pm, Raymond Hettinger <pyt... at rcn.com> wrote:
> > You may have missed my point. I wrote the tools, the docs, and the
> > tests.
> > 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.
> Does the existence of a test case imply a guarantee?
> # Test number of items consumed SF #1171417
> it = iter(range(10))
> self.assertEqual(list(islice(it, 3)), range(3))
> self.assertEqual(list(it), range(3, 10))
That tests a "natural boundary".
In contrast, the OP's issue concerns an odd case where
step > 1
and stop != start + n * step
and len(list(it)) > start + n * step
There's no test for that case and it is not clear
what the desired behavior should be. And AFAICT
there are no use cases or meaningful invariants
to guide the way, so I'm reluctant to lock-in the
choice (much like Tim and Guido waited a long time
before they guaranteed the stability of list.sort()).
If the RightAnswer(tm) is obvious to you, I would
like to hear it. If I had to make a choice right
now, I would choose stopping at the earlier possible
point rather than scanning to the next natural
More information about the Python-list