Lambda in Python 3000

Xah Lee, 200509

On Guido van Rossum's website:
http://www.artima.com/weblogs/viewpost.jsp?thread=98196
dated 20050826, 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 from “filter(F,S)” being cumbersome because
the first argument is a function and that mostly likely it would be a
function that returns true and false thus most people will probably use
the form “lambda” 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(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 being the way they
are already, it is unwise to rewrite every existing Perl program just
because somebody invented another language.

If the predicate in lambda in filter() 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
implementators. And, just before we were using criterion of simplicity.
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 pure
function (lambda) 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 bigshot in the industry of 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 begin to write things like Java: in three thousand words
just to state its puniness.

The removing of elements in a language is in general not a good idea.
Removing powerful features so that cheap coders 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,...

The existance 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 about bags 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.

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 don't really 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 to have
lambda attitude problem). The function map() could also be considered
for expansion. (see “What is Expresiveness 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. filter() should stay as it is as it is superb and
proper.

-------
This post is archived at:
http://xahlee.org/perl-python/python_3000.html

☄