On Sun, May 10, 2020 at 5:00 AM Christopher Barker <pythonchb@gmail.com> wrote:
On Sat, May 9, 2020 at 1:58 PM Alex Hall <alex.mojaki@gmail.com> wrote:
 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).

Is that a major problem? Just use the syntax the way you would use itertools.islice.

Incidentally, I imagine we could allow itertools.islice(iterable, 0, -n) by iterating ahead by n items, keeping them in memory, and stopping when the peeking ahead stops. I can understand though that this comes with some caveats.
 
and well, iterators are already iterators ... so there isn't an "extend the proposal" here at all.

I don't know what you're saying here.
 
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.

Again, it would make exactly as much sense as itertools.islice.
 
> 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 :-)

Most of the points you made in your PEP still apply. itertools.islice is verbose and not particularly readable. I'm not suggesting doing this just to make things a little more convenient.
 
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 "iterator" is a protocol -- anything can support it. That would make it impossible to have a callable be an iterator

`iterator(1:2)` isn't a function call, it isn't valid syntax. The colon would distinguish an islice from a call. But again, while it's techincally unambiguous, it can still be confusing, and you've proven that point.
 
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?

`iterator(1:2)` would compile to roughly `itertools.islice(iterator, 1, 2)`, which would handle the rest at runtime:

- Failing if `iterator` isn't actually an iterator.
- Failing if a negative index is used on something without a length.
- Handling negative indices for sequences (is there any reason we don't have that now?)
- Possibly deferring to a dunder like `__islice__` if one is defined so that some classes (e.g. lists) can return a clever view or something if they want.