[Python-Dev] lambda in Python

Thu May 4 04:09:06 CEST 2006

Today i ran into one of Guido van Rossum's blog article titled 
“Language Design Is Not Just Solving Puzzles” at
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
The article reads very kooky. The bottom line is that Guido simply 
does not like the solution proposed for fixing the lambda construct 
in Python, and for whatever reasons thinks that no solution would 
satisfy him about this. But instead, he went thru sophistry on the 
ignorance and psychology of coder mass in the industry, with mentions 
of the mysterious Zen, the cool Google, the Right Brain, Rube 
Goldberg contraption irrelevancies.
 From his article, i noticed that there's largish thread of 
discussions on lambda.
The following is a essay i wrote after reading another one of Guido 
blog, in which shows prejudice and ignorance about functional 
programing. I hope it can reduce the ignorance about lambda and 
functional programing.
--------------------------
Lambda in Python 3000
Xah Lee, 20050930
On Guido van Rossum's website:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196 (local copy)
dated 20050310, he muses with the idea that he would like to remove 
lambda, reduce(), filter() and map() constructs in a future version 
Python 3000.
Guido wrote:
 «filter(P, S) is almost always written clearer as [x for x in S 
if P(x)], and this has the huge advantage that the most common usages 
involve predicates that are comparisons, e.g. x==42, and defining a 
lambda for that just requires much more effort for the reader (plus 
the lambda is slower than the list comprehension)»
The form “[x for x in S if P(x)]” is certainly not more clear 
than “filter(P, S)”. The latter is clearly a function, what is the 
former? A function every programer in any language can understand and 
appreciate its form and function. Why would anyone to expect everyone 
to appreciate a Python syntactical idiosyncrasy “[x for ...]”?
Also, the argument that the form “filter(F,S)” being cumbersome 
because the first argument is a function and that mostly likely it 
would be a function that returns true/false thus most people will 
probably use the inline “lambda” construct and that is quite 
cumbersome than if the whole thing is written with the syntactical 
idiosyncrasy “[x for ...]”, is rather inane, as you can now see.
The filter(decision_function,list) form is clean, concise, and helps 
thinking. Why it helps thinking? Because it condenses the whole 
operation into its mathematical essence with the most clarity. That 
is, it filters, of a list, and by a yes/no decision function. Nothing 
is more, and nothing can be less. It is unfortunate that we have the 
jargon Lambda and Predicate developed by the tech geekers of the 
functional programing community. The lambda could be renamed Pure 
Function and the Predicate could be called True/False function, but 
the world of things being the way they are already, it is unwise to 
rewrite every existing Perl program just because somebody invented 
another language.
If the predicate P in filter(P,S) is cumbersome, so would exactly the 
same thing appear in the syntactical idiosyncrasy: “[x for x in S if 
P(x)]”.
Guido added this sting as a afterthought:
 «(plus the lambda is slower than the list comprehension)»
Which is faster is really the whim and capacity of Python compiler 
implementators. And, weren't we using clarity as the judgement a 
moment ago? The concept of a function every programer understands, 
but what the heck is a List Comprehension? Why don't you scrap list 
comprehension in Python 3000 and create a table() function that's 
simpler in syntax and more powerful in semantics? ( See http:// 
xahlee.org/perl-python/list_comprehension.html )
 «Why drop lambda? Most Python users are unfamiliar with Lisp or 
Scheme, so the name is confusing; also, there is a widespread 
misunderstanding that lambda can do things that a nested function 
can't -- I still recall Laura Creighton's Aha!-erlebnis after I 
showed her there was no difference! Even with a better name, I think 
having the two choices side-by-side just requires programmers to 
think about making a choice that's irrelevant for their program; not 
having the choice streamlines the thought process. Also, once map(), 
filter() and reduce() are gone, there aren't a whole lot of places 
where you really need to write very short local functions; Tkinter 
callbacks come to mind, but I find that more often than not the 
callbacks should be methods of some state-carrying object anyway (the 
exception being toy programs).»
In the outset Guido here assumes a moronitude about the set of Python 
users and what they are familiar of. Python users 10 years ago are 
not the same Python users today, and will certainly not be the same 
10 years later if you chop off lambda. Things change, math literacy 
advances, and what users you have changes with what you are. A 
function is the gist of a mathematical idea embodied in computer 
languages, not something from LISP or Scheme as tech geekers wont to 
think.
 «... there is a widespread misunderstanding that lambda can do 
things that a nested function can't...»
One is so insulted by a industrial big shot in quoting something so 
disparate then shot it down as if showing his perspicacity.
A lambda is a syntax for function or a name for the concept of 
function. What does it mean that a lambda isn't as powerful as nested 
function??
The lambda in Python is really ill. It is designed with a built-in 
limitation in the first place, and regarded as some foreign substance 
in the Imperative Crowd such as the Pythoners. If there's any problem 
with lambda, it is with lambda in Python and Pythoner's attitude.
 «Also, once map(), filter() and reduce() are gone, there aren't 
a whole lot of places where you really need to write very short local 
functions;»
Of course, one begins to write things like Java: in three thousand 
words just to show you are a moron.
The removing of elements in a language is in general not a good idea. 
Removing powerful features so that coding monkeys can use it is 
moronic. (e.g. Java) Removing “redundant” constructs is not always 
smart (e.g. Scheme), because it pinches on practicality. Removing 
existing language features by a visionary upgrade is a waste. It 
forces unnecessary shakeup and can cause death.
 «So now reduce(). This is actually the one I've always hated 
most, because, apart from a few examples involving + or *, almost 
every time I see a reduce() call with a non-trivial function 
argument, I need to grab pen and paper to diagram what's actually 
being fed into that function before I understand what the reduce() is 
supposed to do. So in my mind, the applicability of reduce() is 
pretty much limited to associative operators, and in all other cases 
it's better to write out the accumulation loop explicitly.»
The existence of reduce() in Python is probably caused by tech 
geeking clowns of the computing industry. Basically, nobody really 
have a clear understanding of mathematics or computing semantics, but 
every elite tech geeker knew one bag of constructs of various 
languages. So, you add this, i want that, and the language becomes a 
incoherent soup of constructs, with the backlash of wanting to chop 
off things again, with that good things.
reduce() in fact embodies a form of iteration/recursion on lists, 
very suitable in a functional language environment. If Python's 
lambda and other functional facilities are more powerful or complete, 
reduce() would be a good addition. For instance, in functional 
programing, it is a paradigm to nest or sequence functions. (most 
readers will be familiar in the form of unix shell's “pipe”). When 
you sequence functions, you can't stop in the middle and do a loop 
construct. So, reduce() and other functional forms of iteration are 
convenient and necessary.
Suggestions: lambda, reduce(), filter() and map() all should stay. 
I'm not sure exactly what's the ins and outs of Python 3000. If one 
wants to shake things up based on a vision: don't. There are already 
gazillion languages and visions; the world really don't need another 
bigshot's say for their personal advancement. As for improvement, 
lambda in Python should be expanded to remove its built-in limitation 
(and Imperative Programing Crowd such as Pythoners should cease and 
desist with their lambda attitude problem). The function map() could 
also be considered for expansion. (see “What is Expressiveness in a 
Computer Language” at http://xahlee.org/perl-python/ 
what_is_expresiveness.html ) Function reduce() should stay because 
it's already there, even if it is not very useful and odd in Python. 
filter() should stay as it is as it is superb and proper.
...
the rest of the article explaining the functions of the functions in 
question is at:
http://xahlee.org/perl-python/python_3000.html
 Xah
 xah at xahlee.org
∑ http://xahlee.org/
☄