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 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? That would allow avoiding itertools when I have no other choice.
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?
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. So maybe we can play with double brackets instead:
```
import itertools
for (l1, r1), (l2, r2) in itertools.product('() {} []'.split(), repeat=2):
print(f'sequence{l1}{l2}1:2{r2}{r1}')
sequence((1:2))
sequence({1:2})
sequence([1:2])
sequence{(1:2)}
sequence{{1:2}}
sequence{[1:2]}
sequence[(1:2)]
sequence[{1:2}]
sequence[[1:2]]
```