_______________________________________________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.-CHBOn Sat, May 9, 2020 at 3:51 AM Chris Angelico <rosuav@gmail.com> wrote:On Sat, May 9, 2020 at 8:00 PM Alex Hall <alex.mojaki@gmail.com> wrote:
>
> On Sat, May 9, 2020 at 11:15 AM Ram Rachum <ram@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-leave@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-leave@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/