The problem is that if you slice twice, or slice after nexting, you can’t get a feel for what the remaining values should be unless you work it through. Of course the exactly same thing is true with using islice twice today, but you don’t _expect_ that to be comprehensible in terms of slicing the original iterable twice, while with slice notation, you do. Or at least I do; maybe that’s just me.

And meanwhile, even though the simple uses aren’t confusing, I’ve never had any code where it made things nicer enough that it seemed worth reaching into the toolbox. But again, maybe that’s just me.

If you want to play with this and can’t implement it yourself easily, I could dig up my implementation. But it’s pretty easy (especially if you don’t try to optimize and just have __getitem__ return a new islice around self).

[1] Actually, I built an incomplete viewtools (a replacement for itertools plus zip, map, etc. that gives you views that are reusable iterables and forward as much input behavior as possible—so map(lambda i: i*2, range(10)) is a sequence, while filter(lambda i: i%2, range(10)) is not a sequence but it is reversible, and so on) and then extracted and simplified the vslice because I thought it might be useful without the views stuff. (I also extracted and simplified it in a different way, as view slices that only work on sequences, and that actually did turn out to be occasionally useful.)