Sean McIlroy wrote:
Alright, now it's too much. It's not enough that you're eliminating it
from the language, you have to stigmatize the lambda as well.

You misunderstand me. I don't have a problem with lambda when it's appropriate, e.g. when used as an expression, where a statement is forbidden. See my post examining some of the uses in the standard library[1]. But when you're defining a named function, you should use the named function construct. That's what it's there for. =)


And besides, it amounts to an explicit declaration that the function
in question has no side effects.

Not at all. Some examples of lambdas with side effects:

py> a
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
NameError: name 'a' is not defined
py> (lambda s: globals().__setitem__(s, 'side-effect'))('a')
py> a
'side-effect'

py> x = (lambda s: sys.stdout.write(s) or s.split())('side effect')
side effect
py> x
['side', 'effect']

py> s = set()
py> x = (lambda x: s.add(x) or x**2)(3)
py> s
set([3])
py> x
9

It is certainly possible to use lambda in such a way that it produces no side effects, but it's definitely not guaranteed by the language.

And besides, it adds flexibility to the language.

I'm not sure I'd agree with flexibility... True, in some cases it can allow more concise code, and occasionally it can read more clearly than the other available options, but since you can use a function created with def anywhere you can use a function created with lambda, I wouldn't say that lambdas make Python any more flexible.


STeVe

[1]http://mail.python.org/pipermail/python-list/2004-December/257990.html
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to