Wouldn't the removal of such functional programming functions make it harder to port programs written in Lisp, Scheme, Logo, and other such so-called `functional' programming languages more difficult if not (im)practically impossible ... as well as programs written in C, c++, or C# which employ the functional style of programming {ref: http://okmij.org/ftp/cpp-digest/Functional-Cpp.html}?

Is functional style programming to be maimed out of existence by lopping off a functional limb at a time until this style of programming is no longer viable?

Removing language constructs (lambda) is a sabotage against users. There is no way (or I do not see any) to make "old" code working when you remove lambda completely without wasting human time resources amount proportional to the size of project. You can define own reduce, you can't define own lambda. Doing such a things without worthy reason (the fact that using lambda may produce hard to understand code - cannot be considered as worthy reason. Any languagy construct may be misused.) - is wrong.

millions of lines of code - complex code, written by experienced mathematicians and physicist - will need to be thrown out the window if python loses that functionality.

it is possible to emulate a parallel computer with map, reduce and lambda.

such that (and i did seriously consider doing this) it is _also_ possible to then do an implementation of those builtin functions on accelerated parallel hardware.

and, yes, such suitable parallel hardware DOES exist: from a company called 'Aspex Microelectronics'. they do a massively parallel array-string processor (SIMD - but not 32 processors, not 64 processors - 4096 2-bit processors with 256 bits of content addressable memory on each 400mhz processor, and the next generation is to have 65536 2-bit processors, at probably 600 to 800mhz)

so.

the thing is: reduce and map could go as 'builtins' and you can write those as functions - but lambda certainly can't go.

removing lambda would be like removing one of the legs of a stool: it will fall over.

List contexts are sufficient to replace many uses of the lambda inline function definition capability. There is one significant annoying consequence of eliminating lambda, however. Without this capability, it becomes more cumbersome to pass a custom cmp() definition to sort().

> I have a list of some records. With lambda I can do:> > my_list.sort(key = lambda x: x.name)> # or> my_list.sort(key = lambda x: x.age)> # or> my_list.sort(key = lambda x: x.address)> > Can I sort list by different keys very easy without lambda?

I think you'll have to define nested functions just prior to calling sort with the key argument. Without lambda, it just can't be done anonymously. The alternative is to make your own python extension that implements sort differently. If sort was implemented so as to order one list (data) according to the default ordering of a second list (keys), then you could avoid the need for lambda altogether when performing custom sort operations. Below is an example I entered into the python command-line interpreter.

I do realise the topic has between returned from the grave to discuss lambda well after it has all been resolved to keep lambda..... at least until 4.0....

but.....

given that features can only be removed for a x.0 release it is not the time to discuss removals anymore it is back to new features.

So we still have lambda and def which have some similarities.

double =lambda (x):x*2is equivalent to def double(x):return x*2

I would suggest that either def should be converted to an expression (which would allow deprecating lambda as a separate solution in the future) or multiline lambdas be allowed (which strangely could allow getting rid of def if we wanted a single solution?)

making def an expression would allow

double=def foodub(x):return x*2

inplace of lambda. The 'foodub' name could be optional for real compatibility where the name is superfluous but even though effectively a comment could aid readability in current situations.. e.g. setHandler(def handler():return 1, .....More importantly there would be a syntax allowing multiline 'lambdas' which there is definitely some call for.

Which to people consider more in keeping with the rest of python....

double =def(x):return x*2 ordef double(x):return x*2?To avoid still needing lambda perhaps the a compiler option for single line defs to return the expression? Unlikely to break many programs and would allowlambda=def to keep old code working

Of course the other idea is to go the other way and allow multiline lambda using the same detection of single vs multline used elsewhere in the language, only allowing termination with ) or , in addition to resetting indent

Fewer ways of expressing something is better than one of them being terse.

Making sense to relative beginners is more important than being natural to people who know math or lisp.

Even though it's a good thing, even though it will be kept, if lambda is being used a lot as a band-aid, a patch on a problem in something else, people ought to think of it as a symptom rather than a feature. That is, the fact that you can wire around problem X with lambda isn't a point for lambda so much as a clue to do something about problem X.

Also, if there are speed differences between different ways of expressing the same thing, that's not a point for the "faster syntax," it's a place to improve the compiler.

I was going to post one of my favorite reduce cases, but noticed a couple other people posted essentially the same thing:

reduce( lambda total,digit: total*base+digit, digits )

where the meanings of *, + and digit vary by context, e.g. polynomials and their coefficients. I'm not sure why Guido thinks associative operators are the only clear uses of reduce, but this is an associative operator (or, an expression that amounts to different associative operators for different data types).

Here is a way to do map() for multiple arrays in parallel with a list comprehension:

[ f( a[i], b[i] ) for i in range( len(a) ) ]

There's an uglier method if you have a variable-length list of arrays to work on.

Perhaps these syntaxes make sense and address some of the awkwardnesses mentioned:

> I actually kind of liked this functions they allowed me to> easily shuffle my work between Scala and Python. Anyway> what would be the clearest/cleanest re-implementation of> the following function?> > > def maxf(f, seq):> '''Returns the element of the sequence that has the> the maximum value after applying the function f '''> return seq and reduce(lambda x,y: f(x)>f(y) and x or y,> y, seq) or None>

Much better to do this:def maxf(f, seq): return seq and max(seq, key=f)