On Nov 5, 3:52 pm, Ian <ian.g.ke...@gmail.com> wrote: > On Nov 5, 2:51 pm, Raymond Hettinger <pyt...@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 boundary. Raymond -- http://mail.python.org/mailman/listinfo/python-list
