+1 I like this! I never considered this idea. It's a good combination of efficiency and elegance.
On Sat, May 9, 2020 at 10:41 PM Christopher Barker <python...@gmail.com> wrote: > 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/ >
_______________________________________________ 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/6SS7FL3XPPEO43RPRYVJPWNKC5J7LMJV/ Code of Conduct: http://python.org/psf/codeofconduct/
