On May 11, 2020, at 10:57, Alex Hall <email@example.com> wrote:
Though it is heading in a different direction that where Andrew was proposing, that this would be about making and using views on sequences, which really wouldn't make sense for any iterator.
The idea is that islice would be the default behaviour and classes could override that to return views if they want.
It is possible to get both, but I don’t think it’s easy.
I think the ultimate unification of these ideas is the “views everywhere” design of Swift. Whether you have a sequence or just a collection or just a one-shot forward-only iterable, you use the same syntax and the same functions to do everything—copy-slicing, view-slicing, chaining, mapping, zipping, etc. And the result is always a view with as much functionality as makes sense (do filtering a sequence gives you a view that’s a reversible collection, not a sequence). So you can view-slice the result of a genexpr the same way you would a list, and you just get a forward-only iterable view instead of a full-fledged sequence view. I’ve started designing such a thing multiple times, every couple years or so, and always realize it’s even more work than I thought and harder to fit into Python than i thought and give up.
But maybe doing it _just_ for view slicing, rather than for everything, and requiring a wrapper object to use it, is a lot simpler, and useful enough on its own.
And that would fit well into the Python way of growing by adding stuff as needed, and only trying to come up with a complete and perfect general design up front when absolutely necessary.