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 email@example.com wrote:
On Sat, May 9, 2020 at 8:00 PM Alex Hall firstname.lastname@example.org wrote:
On Sat, May 9, 2020 at 11:15 AM Ram Rachum email@example.com wrote:
Here's an idea I've had. How about instead of this:
itertools.islice(iterable, 7, 20)
We'll just have:
- More familiar slicing syntax.
- 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)
- 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` followed by `gen`? Is it an error?
Does the generator have to store its past values? Or is `gen` the second item after `gen`? 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 subscripting.
ChrisA _______________________________________________ Python-ideas mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://firstname.lastname@example.org/message/WADS4D... Code of Conduct: http://python.org/psf/codeofconduct/