+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 pythonchb@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 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:
- 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[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/WADS4D... 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/U35BS5... Code of Conduct: http://python.org/psf/codeofconduct/