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. https://github.com/PythonCHB/islice-pep/blob/master/pep-xxx-islice.rst And the prototype implementation: https://github.com/PythonCHB/islice-pep/blob/master/islice.py 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. -CHB On Sat, May 9, 2020 at 3:51 AM Chris Angelico <ros...@gmail.com> wrote: > On Sat, May 9, 2020 at 8:00 PM Alex Hall <alex.moj...@gmail.com> wrote: > > > > On Sat, May 9, 2020 at 11:15 AM Ram Rachum <r...@rachum.com> 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 > subscripting. > > ChrisA > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/WADS4DTEVC63P2O2HPEYY5HVXIGWGWMT/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/U35BS5OIDCGTL3PTY4DDOT43V3PN72LQ/ Code of Conduct: http://python.org/psf/codeofconduct/
