No, I don’t agree with you. They are not a security threat. Prove your point - show how lambda is a security threat - don’t just FUD.
4 Likes
No, people do not agree with that, as already pointed out in the other topic.
Please do not create more topics or derail semi-related ones to have the same discussion.
8 Likes
Sorry - while I also strongly oppose the change proposed by the OP, I also do not agree with you that lambdas “allow for slipping malware”. Obfuscated code can be placed just the same in a defed function, if that is the case. Or an exec expression if you think the problem is putting stuff in a single line.
1 Like
There’s nothing particularly dangerous about lambdas that could not be accomplished with the use of a named function instead.
Returning to the original topic, readability counts. Currently, Python keywords are typically either entire words or are composed of understandable abbreviations of words. This uniformity of style makes for a smooth read. Substituting symbols for words in order to compose keywords would make for a choppy, less pleasant reading of Python code.
Readability counts; but I would make that an argument against current lambda syntax. I find it so clunky that I almost never use a lambda, and I’m a big user of lambda functions in every other language in which I wrote code. Although, admittedly, the greek-letter-keyword doesn’t make the situation better.
What makes current lambda clunky? I find it perfectly fine. If one wants the lambda symbol instead of the text there’s probably a setting in ypur editor of choice that will make lambda the text look like lambda the symbol. I used that quite heavily in latex to make math more readable.
1 Like
Yeah, or even in a font. It’s insanely cool what you can do with ligatures.
1 Like
No idea, but I find expressions with lambdas hard to read. Even a mostly bare map() looks difficult to my eyes:
doubled = map(lambda x: 2*x, [1, 2, 3])
It’s probably the long keyword and the buried : that causes it. If we used not the how-do-I-input-this greek letter, but e.g. the simple slash as in Haskell, I find the situation a little improved:
doubled = map(\x: 2*x, [1, 2, 3])
Still, I find the : off-putting somehow, because actual Haskell lambdas look fine to me:
doubled = map(\x -> 2*x, [1, 2, 3])
Same goes for other common arrow notations:
doubled = map(x => 2*x, [1, 2, 3])
As a matter of fact, to forego the use of lambdas as much as possible, I use a small helper class in my private projects that builds a callable from placeholders:
_x = undef('_x')
doubled = map(2*_x, [1, 2, 3])
3 Likes
But you shouldn’t be using map with inline lambda. You should be using a comprehension instead.
doubled = [2*x for x in [1, 2, 3]]
Lambda functions are much more useful for things like callbacks, where the syntax is far less clunky (and a def function is unnecessarily out-of-line for simple callbacks).
1 Like
Of course, but as I tried to say, that’s a line of code with nothing else going on. Even in that simplest of all uses, I don’t find the current syntax lends itself to be parsed quickly.
1 Like