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). and well, iterators are already iterators ... so there isn't an "extend the proposal" here at all. 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. > 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 :-) 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? > Details to be worked out. As Python as evolved over the years from protocols, to ABC, and it's not fully clear yet, even then, probably, yes "add it to `collections.abc.Sequence`, the builtins, and the stdlib? I"m not sure every class that has __len__ and __getitem__ could Magically grow an new method, and I sure wouldn't want them to. In fact, in theory, you'd want every class that supports slicing to grow this functionality, but I don't know there is any way to know whether a class, in general, supports slicing. 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 "ioterator" is a protocol -- anything can support it. That would make it impossible to have a callable be an iterator > 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? -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
_______________________________________________ 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/6CEBGVDDZIYCIWA2QCBH3G3N3IUFIEBP/ Code of Conduct: http://python.org/psf/codeofconduct/
