On Tue, Jul 19, 2016 at 7:48 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
On 18.07.16 01:21, Wes Turner wrote:
There are a number of generic implementations of these sequence algorithms:

* http://toolz.readthedocs.io/en/latest/api.html#itertoolz
* https://github.com/kachayev/fn.py#itertools-recipes
* http://funcy.readthedocs.io/en/stable/seqs.html
   * http://docs.python.org/2/reference/expressions.html#slicings
   * https://docs.python.org/2/library/itertools.html#itertools.islice
   * https://docs.python.org/3/library/itertools.html#itertools.islice

Aren't all these implementations works with iterables and iterators?

On Jul 17, 2016 3:23 PM, "Serhiy Storchaka"
<mailto:storchaka@gmail.com>> wrote:
 > Maybe it's time to add a new module for sequence-specific functions
(seqtools?). It should contain at least two classes or fabric functions:
 > 1. A view that represents a sliced subsequence. Lazy equivalent of
seq[start:end:step]. This feature is implemented in third-party module
dataview [1].


The result of itertools.islice() is not a sequence.

Additionally, itertools.islice doesn't support negative indexing and it's O(start) to get the first element rather than the O(1) that it could be for sequences.

>>> import itertools
>>> x = range(30)
>>> itertools.islice(x, -2, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Indices for islice() must be None or an integer: 0 <= x <= maxint.

With that said, I've never really worked with sequences that are big enough for the runtime complexity of normal python slicing to actually matter.  I have a feeling that in the typical case, wrapping more abstraction around slicing and creating lazy "views" wouldn't lead to any practical performance benefits.  For the cases where it does lead to practical performance benefits, `numpy` starts to look a whole lot more attractive as an option.  I wonder how many applications would actually benefit from this but can't/shouldn't switch to `numpy` due to other constraints?

 > 2. A view that represents a linear sequence as 2D array. Iterating
this view emits non-intersecting chunks of the sequence. For example it
can be used for representing the bytes object as a sequence of 1-byte
bytes objects (as in 2.x), a generalized alternative to iterbytes() from
PEP 467 [2].



toolz.itertoolz.partition() is just a generator.

Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/




E: matt@getpattern.com // P: 603.892.7736

We’re looking for beta testers.  Go here to sign up!