On Sun, May 10, 2020 at 5:00 AM Christopher Barker <python...@gmail.com> wrote:
> On Sat, May 9, 2020 at 1:58 PM Alex Hall <alex.moj...@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.
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/77OORLTSODLT73BPP3QENHLYRS3BIPIJ/ Code of Conduct: http://python.org/psf/codeofconduct/
