I generally don't use them in programs, but do interactively. The
convenience of being able to say things like
plot( map(lambda x:(x,f(x)), data) )
on the fly is substantial! They did catch me by surprise, though --
don't think they were discussed on the list at all before being announced
as done deals. I had written my own map, filter, & reduce functions _in_
Python before that, & thought that was sufficient. "lambda" was a lot
clumsier to fake, though, so it was a good addition to the built-ins.
Or would have been, if it turns out people view its inclusion as an
implicit promise by you to add lots of other lispish hair <wink/sigh>.
BTW, to the extent that our whining about the "lambda scoping problem"
motivated you to add the default-argument mechanism, adding lambda had
that good effect too <smile>: I was lukewarm about default arguments per
se, but now that they're in I like them very much. Thanks!
> [steve m]
> ... I'm sure you wouldn't want to eliminate 'apply' and resort to:
> ln = len( args )
> if ln == 1 : return f( args[0] )
> elif ln = 2 : return f( args[0], args[1] )
> ...
Before 'apply' was introduced, that's exactly what we did! Brrrrr. I'm
not sure we could write an example using map/lambda/reduce/filter that
Guido would prefer to the loop version, though. But that's OK -- like he
said, he can't take 'em out now, so who cares what he thinks anyway <grin>.
> ... ( And I recall, it was Tim who suggested to me that map + filter
> was the SOLUTION to my complaint that I couldn't put a 'for' and a
> conditional on one line together! )
Well, I'll admit to advancing it as _a_ solution, and one particularly
suited to your particular twist of mind. The alternative
for thing in everything:
if uninteresting(thing): continue
isn't really obnoxious. So how come it irritates us?! I haven't figured
that out yet.
> ...
> Tim also once remarked that one of the things he liked about Python
> was that it didn't force you into a particular style of programming.
OTOH, JAR made the good point that it _does_ tend to force you _not_ to
use a pure style (whether OO or functional or imperative), cuz builtins
come in different flavors (len's a function but not a method, sort's a
method but not a function, etc). Why _doesn't_ that bother us?! I
haven't figured that one out yet either.
> t = [ 60, 20, 40, 40, 40, 40, 80, 40, 40, 80, 40, 40, 90 ]
Hmm! Use 1 for a quarter-note, 2 for a half-note, and 4 for a whole.
"map" the resulting tempo-invariant list to multiply it by the tempo
slowdown factor, and as a low-cost extra beneift you'll get rid of that
crazy "90" at the end <grin>.
> ...
> [ (a,x), (b,y), (c,z) ] = [ a, b, c ] "some-operator" [ x, y, x ]
>
> might well eliminate half of the 'map' usage and make Guido happy,
> and I think it's a useful enough special case that it might deserve
> it's own syntax. ( and get rid of the mysterious looking 'None' ! )
>
> I just don't know what value for "some-operator" makes sense.
If this were Perl, we could talk Larry into using a lowercase "z" as the
infix "zip" operator <wink>.
Seriously, is
>>> def zip(*lists): return apply(map, (None,) + lists)
...
>>> zip( [1,2,3] )
[1, 2, 3]
>>> zip( [1,2,3], ['a','b','c'] )
[(1, 'a'), (2, 'b'), (3, 'c')]
>>> zip( [1,2,3], ['a','b','c'], [{},[],()] )
[(1, 'a', {}), (2, 'b', []), (3, 'c', ())]
>>>
not good enough?
really-grateful-python-didn't-make-me-define-a-zip-object-ly
y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp