I think this is a good idea. For sequences I'm not sure how big the benefit is - I get that it's more efficient, but I rarely care that much, because most lists are small. Why not extend the proposal to all iterators, or at least common ones like generators?
Because the slice syntax, so far at least, only applies to Sequences. And in general, you can't use the full slice syntax on iterators anyway (they don't have a length).
and well, iterators are already iterators ... so there isn't an "extend the proposal" here at all.
But without thinking about i much, I'm not sure adding slice syntax to iterators in general makes sense -- slicing is quite connected to indexing, which iterators don't support.
> That would allow avoiding itertools when I have no other choice.
reading the thread on adding "strict" to zipk I'd say "avoiding itertools" is not really a goal of most folks :-)
You write "This PEP proposes that the sequence protocol be extended". What does that mean exactly? I assume you don't want to magically add an `islice` property to every class that has `__len__` and `__getitem__`. Will you just add it to `collections.abc.Sequence`, the builtins, and the stdlib?
Details to be worked out. As Python as evolved over the years from protocols, to ABC, and it's not fully clear yet, even then, probably, yes "add it to `collections.abc.Sequence`, the builtins, and the stdlib?
I"m not sure every class that has __len__ and __getitem__ could Magically grow an new method, and I sure wouldn't want them to. In fact, in theory, you'd want every class that supports slicing to grow this functionality, but I don't know there is any way to know whether a class, in general, supports slicing.
Perhaps this could come with some new syntax? My first thought was `iterator(1:2)`, the idea being that changing the brackets would give it lazy iterator feel the same way that changing the brackets on a list comprehension turns it into a generator. But it probably looks too much like a function call.
doesn't just look like one -- it would clash. Remember that "iterable" and "ioterator" is a protocol -- anything can support it. That would make it impossible to have a callable be an iterator
So maybe we can play with double brackets instead:
What would this new syntax do, regardless of what it was? I"m not sure I follow. My idea is about creating a view iterable on sequences, I'm not sure what view iterable on an iterable would be?
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython