No function in functional programming allows more than one statement.
That is literally the definition of FP. That the definition of a functions be a singular statement as opposed to a procedural function is a function made up of several statements where each statement has the potential to assign or reassign values. If you write a function with procedures you are not doing functional programming. That's why python lambdas are defined that way.
That being said python doesn't support the let...in expression which is common to do in fp, but neither does JavaScript.
JavaScript just supports anonymous functions that aren't functional. If you make the procedures const then you get something similar to let in which is arguably a trick to make it work.
You can do tricks in python to achieve the same thing with lambdas. In JavaScript you do tricks to make anonymous functions behave like lambdas with let-in, in python you can also do a trick to get let-in behavior in a lambda.
f = lambda x:(
y := 1,
w := 3,
y + w + x)[-1]
Arguably though you shouldn't do this. The pythonic philosophy is that Any function past a certain level of complexity you should just use def rather then inline it. This philosophy still applies in FP.
Ultimately these are minor syntactic and stylistic differences involving trivial sugar.
I don't think python will "correct it" because from their perspective there is nothing to correct. Make your function a def. That's the pythonic way.
The first class support for for pipe operators and what not are not present in JavaScript or python. It's not showstoppers. But in python it is possible to get composition working with magic method operating overloading. It's just not first class.
Fp in js never involved the algebraic operator style promoted by haskell. In this sense it's more lisp style and python is similar to js in this respect.
> lambda functions in python have as much expressive power as any function.
There is no fundamental reason why Python doesn’t have let, and there is no fundamental reason to not be able to catch exceptions within a lambda. Python already fixed the unneeded print statement in its history so I think there is hope. (I don’t think js is relevant here; I was trying to explain why lispers or people who like Haskell may revisit their improved expressive environments).
That is literally the definition of FP. That the definition of a functions be a singular statement as opposed to a procedural function is a function made up of several statements where each statement has the potential to assign or reassign values. If you write a function with procedures you are not doing functional programming. That's why python lambdas are defined that way.
That being said python doesn't support the let...in expression which is common to do in fp, but neither does JavaScript.
JavaScript just supports anonymous functions that aren't functional. If you make the procedures const then you get something similar to let in which is arguably a trick to make it work.
You can do tricks in python to achieve the same thing with lambdas. In JavaScript you do tricks to make anonymous functions behave like lambdas with let-in, in python you can also do a trick to get let-in behavior in a lambda.
Arguably though you shouldn't do this. The pythonic philosophy is that Any function past a certain level of complexity you should just use def rather then inline it. This philosophy still applies in FP.Ultimately these are minor syntactic and stylistic differences involving trivial sugar.
I don't think python will "correct it" because from their perspective there is nothing to correct. Make your function a def. That's the pythonic way.
The first class support for for pipe operators and what not are not present in JavaScript or python. It's not showstoppers. But in python it is possible to get composition working with magic method operating overloading. It's just not first class.
Fp in js never involved the algebraic operator style promoted by haskell. In this sense it's more lisp style and python is similar to js in this respect.