On Thu, 11 Mar 2004 12:55:20 -0000, claird at lairds.com (Cameron Laird)
>In article <2f9050pq22u53o7aqo9i8ebqj11vo9kilg at 4ax.com>,>David MacQuigg <dmq at gain.com> wrote:> .> .> .>>going to help me write some code, I won't have time to study it. My>>understanding of lambda functions is simply that they are a way to>>squeeze functions into a tight space:>>>>list_of_funcs = [(lambda x: 2**x), (lambda x: 3**x), (lambda x: 4**x)]>>>>If you are not concerned about space, simply use normal defs:>>>>def f2(x): return 2**x>>def f3(x): return 3**x>>def f4(x): return 4**x>>list_of_funcs = [f2, f3, f4]>>>>Is there any other reason in Python to use lambdas?> .> .> .>In fact, *that*'s not a reason. Part of tribal lore--a true,>documented part, by the way--is that Big Cheese Guido depre->cates lambdas. He says they're a mistake, and people shouldn't
Wow!! And I thought it was just me. Could you point me to a PEP or
other discussion? I would sure like to know the history of this.
Could it be that in adding "lambda calculus" to Python, Guido was
snowed by the language theorists? <half wink>
I think it is really cool that a language can actually have a mistake
like this corrected. In the commercial world I'm used to, such a
feature would become part of the core religion, and any questioning
would eventually be met with "There are just some things you can't
understand. Get back to work!"
>be using 'em. Whenever you feel like a lambda, define a named>function; it forces the developer to come up with a name for>the operation, and that's likely to make the code more read->able (I'm slightly abbreviating the argument here).>>Space, in the sense you're using it above, should NOT concern>Pythoneers. Correctness and clarity of express should.
>It pains my sensitivities every time you claim lambdas are>just a way of making functions "small". Again, I understand>how natural that is from your background. Around this >mathematician, 'twould be less distracting to run your finger->nails down a chalkboard.
Sorry for the pain, and many thanks for the enlightenment.
>I think this ties back to your broader original propositions:>the Python aesthetic assesses little merit for the brevity of>@-anything, and much for the presumed evocativeness of "yield".>An abundance of *good* keywords is a good thing. That's>definitely not the attitude of all languages.
I agree that brevity in itself has little merit. This whole
side-discussion on lambdas was on the presumption that brevity was the
intent. I now think deprecation of this wart is the better
The choice between adding a keyword and modifying an existing
statement with a standard 'modify' symbol may now be largely a matter
of personal preference. ( 'yield' vs @return, 'self.x' vs @x ).
Still, there is a small syntactic burden added with each keyword. We
just have to be careful that the benefit (evoking an instant meaning
to the majority of users) is actually realized.
A new keyword 'printraw', would certainly do that. It just doesn't
feel right to me, however. So if we can't have
print @(separator = None) x,y,z
then I would opt for deprecating 'print' and going with the function
syntax proposed by Paul Prescod:
show(x,y,z, separator = None)