[Python-ideas] [Python-Dev] Proposal: new list function: pack

[Josiah Carlson]

iwinslice() is just as bad of a name as any of the others.

I have seen the equivalent of window(iterator, size=2, step=1), which
works as you would expect (both as the output, as well as the
implementation), with size and step both limited to 5 (because if you
are doing things with more than 5 items at a time...you probably
really want something else, and in certain cases, you can use multiple
window calls to compose larger groups).

I'd be a -0 on the feature, because as Raymond says, it's trivial to
implement with a deque.  And as I've said before, not all x line
functions should be built-in.

 - Josiah

On Fri, Mar 20, 2009 at 10:32 AM, paul bedaride <paul.bedaride at gmail.com> wrote:
> Now I discover itertools I thing your are right, but maybe the pack
> function could be
> rename iwinslice (at the end it's its real name), and add it to itertools ??
>
> paul bedaride
>
> On Fri, Mar 20, 2009 at 6:01 PM, Raymond Hettinger <python at rcn.com> wrote:
>>
>>>> I propose a new function for list for pack values of a list and
>>>> sliding over them:
>>>>
>>>> then we can do things like this:
>>>> for i, j, k in pack(range(10), 3, partialend=False):
>>>> print i, j, k
>>
>> . . .
>>>>
>>>> def pack(l, size=2, slide=2, partialend=True):
>>>> lenght = len(l)
>>>> for p in range(0,lenght-size,slide):
>>>> def packet():
>>>> for i in range(size):
>>>> yield l[p+i]
>>>> yield packet()
>>>> p = p + slide
>>>> if partialend or lenght-p == size:
>>>> def packet():
>>>> for i in range(lenght-p):
>>>> yield l[p+i]
>>>> yield packet()
>>
>> This has been discussed before and rejected.
>>
>> There were several considerations.  The itertools recipes already include
>> simple patterns for grouper() and pairwise() that are easy
>> to use as primitives in your code or to serve as models for variants.
>> The design of pack() itself is questionable.  It attempts to be a Swiss Army
>> Knife by parameterizing all possible variations
>> (length of window, length to slide, and how to handle end-cases).
>> This design makes the tool harder to learn and use, and it makes
>> the implementation more complex.
>> That complexity isn't necessary.  Use cases would typically fall
>> into grouper cases where the window length equals the slide
>> length or into cases that slide one element at a time.  You don't
>> win anything by combining the two cases except for more making
>> the tool harder to learn and use.
>>
>> The pairwise() recipe could be generalized to larger windows,
>> but seemed like less of a good idea after closely examining potential
>> use cases.  For cases that used a larger window, there always
>> seemed to be a better solution than extending pairwise().  For
>> instance, a twenty-day moving average is better implemented with
>> a deque(maxlen=20) and a running sum than with an iterator
>> returning tuples of length twenty -- that approach does a lot of
>> unnecessary work shifting elements in the tuple, turning an
>> O(n) process into an O(m*n) process.
>>
>> For short windows, like pairwise() itself, the issue is not one of
>> total running time; instead, the problem is that almost every proposed use
>> case was better coded as a simple Python loop,
>> saving the value previous values with a step like:  oldvalue = value.
>> Having pairwise() or tripletwise() tended to be a distraction away
>> from better solutions.  Also, the pure python approach was more
>> general as it allowed accumulations:  total += value.
>> While your proposed function has been re-invented a number of
>> times, that doesn't mean it's a good idea.  It is more an exercise
>> in what can be done, not in what should be done.
>>
>>
>> Raymond
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>