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.
5 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.
9 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.
2 Likes
There’s nothing particularly dangerous about lambdas that could not be accomplished with the use of a named function instead.
1 Like
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.
1 Like
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])
4 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.
2 Likes
Still, I find the : off-putting somehow, because actual Haskell lambdas look fine to me:
I like that too, and plenty of other languages define anonymous functions like that.
Is there any serious discussion, of having a shorter, more intuitive, syntax for lambdas, after three years? I think beginners in programming are very unlikely to have heard of a lambda function. It is a keyword name, even something like func x, y, z: x + y + z would be more intuitive.
It also reminds me of general math notation:
Edit: Discourse did something weird to the formatting, no idea why the first line is out of the quote box.
The \ works in Haskell/R as others have noted.
In R one can write:
lapply(seq, \(x) {x *x}
The parentheses around x are mandatory. In python I think this doesn’t even look so bad:
map((\x: x*x), range(10))
If you want to use λ, I actually wrote [a package](uneval · PyPI) that let’s you do this:
from uneval import λ
map(λ.x("x*x"), range(10))
It’s an alias for F which is easier to type. I would only ever use it for code that is very lambda-heavy (some pyspark code).
I personally use us/international and us/symbolic, and lambda is quite easy to type: altGr (right alt) + L.
Still, your point holds for most people.
My problem is it seems I don’t understand name spaces/context for lambda.
I wrote this because I couldn’t get it to work with a lambda, even with lambda o=o: …`. The lambada would bind to the last o, breaking the desired semantics.
def wrap(o) -> Callable[[Any], Any]:
return o._parse
ch.options = [wrap(o) for o in self.options]
(post deleted by author)