This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Final state of underlying sequence in islice
Type: behavior Stage:
Components: Documentation Versions: Python 3.2
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: ned.deily, rhettinger, shashank, terry.reedy
Priority: low Keywords:

Created on 2010-11-05 10:13 by shashank, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (3)
msg120482 - (view) Author: Shashank (shashank) Date: 2010-11-05 10:13
-- Converting the discussion here http://mail.python.org/pipermail/python-list/2010-November/1259601.html to a bug report (+nosy for everyone that responded, quoting the initial message for context)

Are there any promises made with regard to final state of the underlying sequence that islice slices?
for example consider this

>>> from itertools import *
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
51

Now, the doc [1] says "If stop is None, then iteration continues until the iterator is exhausted, if at all; otherwise, it stops at the specified position".
It clearly is not stopping at stop (3).

Further, the doc gives an example of how this is *equivalent* to a generator defined in the same section. It turns out, these two are not exactly the
same if the side-effect of the code is considered on the underlying sequence.

Redefining islice using the generator function defined in the doc gives different (and from one pov, expected) result
>>> def islice(iterable, *args):
...     # islice('ABCDEFG', 2) --> A B
...
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
2

While "fixing" this should be rather easy in terms of the change in code required it might break any code depending
on this seemingly incorrect behavior
msg120483 - (view) Author: Shashank (shashank) Date: 2010-11-05 10:25
@Raymond: I don't have a particular use case where I had a problem with this behavior. I came across this "problem" when looking at this issue http://bugs.python.org/issue6305.

An important problem that can happen with this behavior is that it does extra work that is not needed. Consider the case (it appears in Lib/test/test_itertools.py):

islice(count(), 1, 10, maxsize)

where maxsize is MAX_Py_ssize_t

Current implementation goes all the way up to maxsize when it should have just stopped at 10.

You are probably right in saying that the caller can make sure that the parameters are such that such cases don't arise but I would still like to see python doing the best possible thing as far as possible.
msg122877 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2010-11-30 02:50
Fixed in r86874.
History
Date User Action Args
2022-04-11 14:57:08adminsetgithub: 54532
2010-11-30 02:50:36rhettingersetstatus: open -> closed
resolution: fixed
messages: + msg122877
2010-11-05 16:56:49rhettingersetpriority: normal -> low
assignee: rhettinger
components: + Documentation, - Interpreter Core
versions: - Python 3.1, Python 2.7
2010-11-05 10:25:30shashanksetmessages: + msg120483
2010-11-05 10:13:38shashankcreate