Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!selfless.tophat.at!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Terry Reedy <tjreedy@udel.edu>
Subject: Re: Lambda question
Date: Mon, 06 Jun 2011 12:52:31 -0400
References: <20110606134215.3EYA9.180297.root@cdptpa-web25-z02>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
In-Reply-To: <20110606134215.3EYA9.180297.root@cdptpa-web25-z02>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2494.1307379170.9059.python-list@python.org>
Lines: 79
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:7095

On 6/6/2011 9:42 AM, jyoung79@kc.rr.com wrote:
>>>>>> f =3D lambda x, n, acc=3D[]: f(x[n:], n, acc+[(x[:n])]) if x else =
acc
>
>> Packing tail recursion into one line is bad for both understanding and=

>> refactoring. Use better names and a docstring gives
>>
>> def group(seq, n):
>>     'Yield from seq successive disjoint slices of length n plus the
>> remainder'
>>     for i in range(0,len(seq), n):
>>       yield seq[i:i+n]

[I added back the last 'n' that got deleted somehow]

> Thank you all very much for this incredible help!  The original code
> now makes sense, and I was thrilled to see better and more efficient
> ways of doing this.  Thanks for taking the time to share your
> thoughts as well as the excellent detail everyone shared=E2=80=A6  I re=
ally
> appreciate it!

You are welcome.

Let me add something not said much here about designing functions: start =

with both a clear and succinct definition *and* test cases. (I only=20
started writing tests first a year ago or so.) Test cases help test the=20
definition statement as well as the yet-to-be-written code. They also=20
make re-factoring much safer. I think test cases should start with null=20
inputs. For this function:

for inn,out in (
         (('',1), []), # no input, no output
         (('abc',0), []), # definition unclear, could be error
         (('abc',1), ['a','b','c']),
         (('abcd',2), ['ab','cd']),
         (('abcde',2), ['ab', 'cd', 'e']), # could change this
         ):
     assert list(group(*inn)) =3D=3D out, (inn,out)

This fails with
ValueError: range() arg 3 must not be zero

I will let you think about and try out what the original code 'f=3D../=20
does with n=3D0. It is not good. A third problem with lambda expressions =

is no test for bad inputs. They were added to Python for situations=20
where one needs a function as an argument and and the return expression=20
is self-explanatory, clearly correct, and safe for any inputs it could=20
get in the context it is passed into. For example, lambda x: 2*x.

This works:

def group(seq, n):
   'Yield from seq successive disjoint slices of length n & the remainder=
'
   if n<=3D0: raise ValueError('group size must be positive')
   for i in range(0,len(seq), n):
     yield seq[i:i+n]

for inn,out in (
         (('',1), []), # no input, no output
         #(('abc',0), ValueError), # group size positive
         (('abc',1), ['a','b','c']),
         (('abcd',2), ['ab','cd']),
         (('abcde',2), ['ab', 'cd', 'e']), # could change this
         ):
     assert list(group(*inn)) =3D=3D out, (inn,out)

I have written a function test function that I will post or upload to=20
PyPI sometime. It accepts i/o pairs with error 'outputs', like the one=20
commented out above.

--=20
Terry Jan Reedy