Funny you should bring this up.

I've been meaning, for literally years, to propose not quite this, but adding a "slice iterator" to the sequence protocol.

(though note that one alternative is adding slice syntax to itertools.islice)

I even got  so far as to write a draft PEP and prototype.

NOTE: I'm not saying this is ready for a PEP, but it was helpful to use the format to collect my thoughts.

And the prototype implementation:

I never got around to posting here, as I wasn't quite finished, and was waiting 'till I had time to deal with the discussion.

But since it was brought up -- here we go!

If folks have an interest in this, I'd love to get feedback.


On Sat, May 9, 2020 at 3:51 AM Chris Angelico <> wrote:
On Sat, May 9, 2020 at 8:00 PM Alex Hall <> wrote:
> On Sat, May 9, 2020 at 11:15 AM Ram Rachum <> wrote:
>> Here's an idea I've had. How about instead of this:
>> itertools.islice(iterable, 7, 20)
>> We'll just have:
>> itertools.islice(iterable)[7:20]
>> Advantages:
>> 1. More familiar slicing syntax.
>> 2. No need to awkwardly use None when you're interested in just specifying the end of the slice without specifying the start, i.e. islic(x)[:10] instead of islice(x, None, 10)
>> 3. Doesn't require breaking backwards compatibility.
>> What do you think?
> Looking at this, my train of thought was:
> While we're at it, why not allow slicing generators?

Bear in mind that islice takes any iterable, not just a generator. I
don't think there's a lot of benefit in adding a bunch of methods to
generator objects - aside from iteration, the only functionality they
have is coroutine-based. There's no point implementing half of
itertools on generators, while still needing to keep itertools itself
for all other iterables.

> And if we do that, what about regular indexing?
> But then, what if I do `gen[3]` followed by `gen[1]`? Is it an error? Does the generator have to store its past values? Or is `gen[1]` the second item after `gen[3]`? Or wherever the generator last stopped?

It makes no sense to subscript a generator like that.

> Well that's probably why I can't index or slice generators - so that code doesn't accidentally make a mess trying to treat a transient iterator the way it does a concrete sequence. A generator says "you can only iterate over me, don't try anything else".
> Which leads us back to your proposal. `islice(iterable)[7:20]` looks nice, but it also allows `foo(islice(iterable))` where `foo` can do its own indexing and that's leading to dangerous territory.

If foo can do its own indexing, it needs to either specify that it
takes a Sequence, not just an Iterable, or alternatively it needs to
coalesce its argument into a list immediately. If it's documented as
taking any iterable, it has to just iterate over it, without

Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct:

Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython