Python complaints
Tim Peters
tim_one at email.msn.com
Mon Dec 13 17:11:41 EST 1999
[Ivan Van Laningham]
> ... [buncha code] ...
> 1) In the 'tm.add_command(...)' line, how would list
> comprehensions replace the
> 'command=lambda m=elements[ne]:setimage(m)'
> How would they work? Please explain for bears of very small mind;-)
>
> 2) In the Pythonian world of today (or is this the "Postpythonian
> world?"), how would one avoid the use of lambda and still use only one
> callback to handle every constructed entry in the menus?
lambda is never needed. Where you have
... lambda args: xxx ...
today,
def _(args): return xxx
... _ ...
was usable the day before lambda was introduced <wink>. The uses of lambda
in your code are exactly why lambda was introduced: as a minor
convenience -- but no more than that.
tm.add_command(label=elements[ne],
command=lambda m=elements[ne]:setimage(m))
vs
def _(m=elements[ne]): return setimage(m)
tm.add_command(label=elements[ne], command=_)
If people *stuck* to trivial uses like that, Guido wouldn't have come up
with the delightful characterization of Python's lambda/map/etc as "minor
nuisances" <wink>.
BTW, the 2nd (pre-lambda) form above is, to me, significantly more readable!
In large part because of the clumsiness introduced by abusing the default
argument mechanism to sneak "elements[ne]" across the scope boundary.
Spreading that tomfoolery across stmts makes it easier to see what's going
on. The Python lambda is mostly a hack -- albeit one that does add minor
convenience <wink>.
[François Pinard]
>> Guido could keep `map', `reduce' and `filter', and get rid of `lambda'.
>> I guess it might solve the bigger part of the political problem. :-)
I doubt he'll get rid of anything; but adding list comprehensions would
provide a way for people without a Lispish background to avoid most uses of
map and filter, and hence for non-GUI people also most uses of lambda.
People with a Lispish background would like them too, despite their certain
a priori claim to despise and abhor them <wink>.
unreadable-isn't-*always*-better-ly y'rs - tim
More information about the Python-list
mailing list