A critic of Guido's blog on Python's lambda

[Xah Lee]

Python, Lambda, and Guido van Rossum

Xah Lee, 2006-05-05

In this post, i'd like to deconstruct one of Guido's recent blog about
lambda in Python.

In Guido's blog written in 2006-02-10 at
http://www.artima.com/weblogs/viewpo...?thread=147358

is first of all, the title “Language Design Is Not Just Solving
Puzzles�. In the outset, and in between the lines, we are told that
“I'm the supreme intellect, and I created Python�.

This seems impressive, except that the tech geekers due to their
ignorance of sociology as well as lack of analytic abilities of the
mathematician, do not know that creating a language is a act that
requires little qualifications. However, creating a language that is
used by a lot people takes considerable skill, and a big part of that
skill is salesmanship. Guido seems to have done it well and seems to
continue selling it well, where, he can put up a title of belittlement
and get away with it too.

Gaudy title aside, let's look at the content of his say. If you peruse
the 700 words, you'll find that it amounts to that Guido does not like
the suggested lambda fix due to its multi-line nature, and says that he
don't think there could possibly be any proposal he'll like. The
reason? Not much! Zen is bantered about, mathematician's impractical
ways is waved, undefinable qualities are given, human's right brain is
mentioned for support (neuroscience!) , Rube Goldberg contrivance
phraseology is thrown, and coolness of Google Inc is reminded for the
tech geekers (in juxtaposition of a big notice that Guido works
there.).

If you are serious, doesn't this writing sounds bigger than its
content? Look at the gorgeous ending: “This is also the reason why
Python will never have continuations, and even why I'm uninterested in
optimizing tail recursion. But that's for another installment.� . This
benevolent geeker is gonna give us another INSTALLMENT!

There is a computer language leader by the name of Larry Wall, who said
that “The three chief virtues of a programmer are: Laziness,
Impatience and Hubris� among quite a lot of other ingenious
outpourings. It seems to me, the more i learn about Python and its
leader, the more similarities i see.

So Guido, i understand that selling oneself is a inherent and necessary
part of being a human animal. But i think the lesser beings should be
educated enough to know that fact. So that when minions follow a
leader, they have a clear understanding of why and what.

----

Regarding the lambda in Python situation... conceivably you are right
that Python lambda is perhaps at best left as it is crippled, or even
eliminated. However, this is what i want: I want Python literatures,
and also in Wikipedia, to cease and desist stating that Python supports
functional programing. (this is not necessarily a bad publicity) And, I
want the Perl literatures to cease and desist saying they support OOP.
But that's for another installment.

----
This post is archived at:
http://xahlee.org/UnixResource_dir/w...bda_guido.html

Â* Â* Xah
Â* Â* xa*@xahlee.org
∑ http://xahlee.org/

[Martin Rydstr|m]

al***@mac.com (Alex Martelli) writes:

Didn't want to trigger some flamewar;-), but, yes, if that was my only
choice, I'd much rather use small, simple Scheme than huge, complicated,
rich, powerful Common Lisp. ((But in this case I'm biased by early
experiences, since when I learned and used Lisp-ish languages there WAS
no Common Lisp, while Scheme was already there, although not quite the
same language level as today, I'm sure;-)).

If that was in the early to mid eighties, which I seem to recall you
mentioning, the Lisp dialects mostly in use were huger, more
complicated, richer and more powerful than Common Lisp in many, if not
most, respects, as far as I can tell. Common Lisp is a (later)
augmented least common denominator of those Lisps. The really big
thing that's newer and greater in CL is CLOS and the condition system.

',mr

--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_

[Petr Prikryl]

"Alex Martelli" wrote...

Joe Marshall wrote:
...

If you language allows unnamed integers, unnamed strings, unnamed
characters, unnamed arrays or aggregates, unnamed floats, unnamed
expressions, unnamed statements, unnamed argument lists, etc. why
*require* a name for trivial functions?
Event the trivial function can have a name. Does it make
the trivial function more understandable if I do not give a name?
I understand what lambda means, but it is clearer for me to see
something like (with more meaningful name than shown here):

def fn(x): ... return x + 5

and to use it like...
fn(3) 8

Still, I can anonymize it later, if I really need
a = [fn]
or I can give it another name
z = fn
In my opinion, the cry for lambda in Python comes
from people used to functional languages, because
they are not used to the procedural style and it
does not fit them at the beginning.
Frankly, functional style seems "more strange" to me
(i.e. the counter example). Still, I do not say it is bad.
But it never came to my mind to say "Please, rewrite
the LISP so that it looked more like Pascal. I do not like
the lambda."

Also, Python is compiled (to bytecode), imperative language,
and the form of definition of the chunks of code is more
natural to the compiler and to the customs
how the procedural program is written and how its parts
are referenced and put together to form bigger chunks
of code.

I think it's reasonable to make a name a part of functions, classes and
modules because they may often be involved in tracebacks (in case of
uncaught errors): to me, it makes sense to let an error-diagnosing
tracebacks display packages, modules, classes and functions/methods
involved in the chain of calls leading to the point of error _by name_.

I agree with Alex here. I USUALLY do not need debugger, but sometimes
it is exremely handy to discover what happens (through debugger or few
print commands, its a matter of taste). And Python is very fine here:
dir(fn) ['__call__', '__class__', '__delattr__', '__dict__', '__doc__',
'__get__',
'__getattribute __', '__hash__', '__init__', '__module__', '__name__',
'__new__', '__reduce__', '__reduce_ex__' , '__repr__', '__setattr__',
'__str__', 'func_closure', 'func_code', 'func_defaults' , 'func_dict',
'func_doc', 'func_globals', 'func_name'] fn.__name__ 'fn'

and even the anonymized function still knows its original name and type
a[0].__name__ 'fn' type(a[0]) <type 'function'>

If lambda functions in Python are tweaked internally into normal Python
functions...
z = lambda x: x * 3
dir(z) ['__call__', '__class__', '__delattr__', '__dict__', '__doc__',
'__get__',
'__getattribute __', '__hash__', '__init__', '__module__', '__name__',
'__new__', '__reduce__', '__reduce_ex__' , '__repr__', '__setattr__',
'__str__', 'func_closure', 'func_code', 'func_defaults' , 'func_dict',
'func_doc', 'func_globals', 'func_name'] z.__name__ '<lambda>' type(z)

<type 'function'>

.... what makes them better, than the named function? If I do not loose
anything by simplification, I want to have it simpler.

pepr

[M Jared Finder]

Alex Martelli wrote:

Stefan Nobis <sn****@gmx.d e> wrote:

al***@mac.com (Alex Martelli) writes:

if anonymous functions are available, they're used in even more
cases where naming would help

Yes, you're right. But don't stop here. What about expressions? Many
people write very complex expression, that are hard to understand. A
good language should forbid these abuse and don't allow expressions
with more than 2 or maybe 3 operators!

That would _complicate_ the language (by adding a rule). I repeat what
I've already stated repeatedly: a good criterion for deciding which good
practices a language should enforce and which ones it should just
facilitate is _language simplicity_. If the enforcement is done by
adding rules or constructs it's probably not worth it; if the
"enforcemen ts" is done by NOT adding extra constructs it's a double win
(keep the language simpler AND push good practices).

Your reasoning, taken to the extreme, implies that an assembly language,
by virtue of having the fewest constructs, is the best designed language
ever. But we know that not to be the case -- rarely do even embedded
developers program in assembly language any more. Why?

Because assembly language is so simple that it's very tedious to write.
There's no function call primitive -- you have to manually generate a
function call pattern yourself. There's no looping primitive -- you
have to manually generate a looping pattern yourself. I feel sorry for
the person who's debugging an assembly program using manually generated
code that implements a vtable-based dynamic dispatch.

Any feature that allows me to write less code to do the same thing has a
huge positive -- the reduction of human generated, and therefore error
prone, code. I think the advantages of anonymous functions:
a) explicitly documenting that the function is used in only one place
b) enabling generic iteration and looping routines
c) not having to maintain a unique name for the function
d) making the language more elegant
e) making the language simpler to implement
greatly outweigh the small disadvantage of adding one additional
construct to the language.

-- MJF

[Petr Prikryl]

"Chris Uppal" wrote...

Alex Martelli wrote:

I think it's reasonable to make a name a part of functions, classes and
modules because they may often be involved in tracebacks (in case of
uncaught errors): to me, it makes sense to let an error-diagnosing
tracebacks display packages, modules, classes and functions/methods
involved in the chain of calls leading to the point of error _by name_.

[...] E.g. consider the Smalltalk code (assumed to be the body of a method):

aCollection
do: [:each |
each > 0 ifTrue: [^ true]].
^ false.

which iterates over a collection checking to see if any element is > 0. If so then the method answers true ("^" -- spelled "return" in Java), otherwise it answers false. In that code,
[^ true]
is syntactically and semantically an anonymous function, which is only invoked if the antecedent is true (in point of fact the compiler inlines that function away but I don't think that's relevant here). The passage beginning
[:each | ...
and reaching to the matching ] is also an anonymous function with one parameter (each) which is applied to each element of the collection in turn. (In this case it really is an anonymous function, even at the implementation level.) What "name" would you give to either of them ? I don't believe that /any/ name is possible, and certainly that no name is desirable.

for element in aCollection:
if element > 0:
return True
return False

And adding "def test(aCollectio n):" does not make it more complex,
in my opinion. And possibly, the chunk of code may be written
in some other way, more Pythonically. Maybe the attempt to
rewrite programs from other languages into Python and
the effort to use the same "tricks" like in the original program,
causes the cry for preserving lambda in future Python.

pepr

[Michele Simionato]

Ken Tilton wrote:

I was not thinking about the thread issue (of which I know little). The
big deal for Cells is the dynamic bit:

(let ((*dependent* me))
(funcall (rule me) me))

Then if a rule forces another cell to recalculate itself, *dependent*
gets rebound and (the fun part) reverts back to the original dependent
as soon as the scope of the let is exited.

Python 2.5 has a "with" statement (yes, the name is Lispish on purpose)
that could be used to implement this. See
http://www.python.org/dev/peps/pep-0343

Michele Simionato

[Antoon Pardon]

Op 2006-05-09, Pisin Bootvong schreef <jo********@gma il.com>:

Antoon Pardon wrote:

Op 2006-05-09, Pisin Bootvong schreef <jo********@gma il.com>:

>
> Antoon Pardon wrote:
>> Op 2006-05-09, Pisin Bootvong schreef <jo********@gma il.com>:
>> > Is this a Slippery Slope fallacious argument?
>> > (http://c2.com/cgi/wiki?SlipperySlope)
>>
>> No it is not.
>>
>> [...]
>>
>> So the question I have is: Why is requiring me to give this function
>> a name considered a good thing, when it leads to a situation that
>> is considered bad practice in case of a number.
>>
>> --
>
> Slippery Slope::
> "Argumentat ion that A is bad, because A might lead to B, and B
> to C, and we all know C is very bad."
But I have seen noone here argue that requiring functions to be named
leads to requiring all variables to be named.

If I misinterpret your intended meaning, then I'm terribly sorry.
However let me clarify how I understand your statements -- English is
not my native language but I'm quite sure I have good English skill.

you said:

>> Why is requiring me to give this function
>> a name considered a good thing, when it leads to a situation that
>> is considered bad practice in case of a number.
So in that question, one of the your assumption is that:

"it (required function naming) ***LEADS*** to a situation that is
considered bad practice in case of a number (required number naming)"

The bad practice I was talking about was that the number was essentially
given a meaningless name that didn't add any information. There is
no adavantage using 'one' as a variable name over using 1 directly.

If for some reason I needed a 2 in the code every time 'one' was
used, I can hardy turn

one = 1

into

one = 2

Because people would still see things like:

foo(one)

In the cade and would expect this to be equivallent with

foo(1)

and not the equivallent of

foo(2)
You have not seen anyone here "argue that requiring functions to be named leads to requiring all variables to be named"

But obviously I have seen someone "argue that requiring functions to be
named leads to requiring **NUMBER** to be named"
IMO you misinterpreted someome's word that way.
And you said that requiring number to be named is bad.
Yes that is the starting point. But that is just an
example of what bad practices will follow: the use
of meaningless names.
Where did I misunderstand that you, with all good faith, were not
trying to say that "A leads B which is bad so "why is A considered a
good thing""? And how is it not slippery argument?
This is my argument:

1) Using meaningless names is a bad coding practice. (with the number example)
2) Requiring names in particular circumstances will
lead to meaninless names in those circumstances.
3) Requiring names for functions will lead to
meanless names for some functions.
4) Requiring names for functions will thus lead to
bad coding practice in a number of cases.
To put my response another way, I would ask:
Does Python require you to name all your number? expression? (Hint: the
answer is no)

So where did you get the idea that requiring function to be named, as
Python does, leads to requiring number to be named? Is it in a research
anywhere? Or do majority of people here agree so (that it leads to)?

I didn't get that idea.

>> Why is requiring me to give this function
>> a name considered a good thing, when it leads to a situation that
>> is considered bad practice in case of a number.
>
> A === "requiring me to give function a name"
> no B
> C === "requiring me to give number a name"
>
> "Argumentat ion that requiring one to give function a name is bad,
> because that might lead to requiring one to give number a name, and we
> all know that that is very bad."

That is not the arguement I'm making.

The argument is that a particular pratice is considered bad coding,
(with an example giving a number) and then showing that requiring
a name for a function, almost makes such a practice inevitable (for
certain functions used as parameters)

Your example:

def incr_cnt_by_one (obj):
obj.cnt += 1

treat_all(lst, incr_cnt_by_one )

Did not in anyway show that the number one is required to be named. 1
in that code is written literally; you didn't have to write "one = 1"
first. The function to increment obj.cnt by one is named. but the
number 1 itself is not named.

You missed the point entirely. Isn't "one" a horrible name to use?
It doesn't buy you anything over the use of 1 and may even cause
confusion should anyone ever write something like one = 2.

And isn't incr_cnt_by_one just as horrible a name to use. If I ever
needed another function I couldn't just use another body with
the same function name because something like

def incr_cnt_by_one (obj):
obj.buzy = False

would probably cause just as much confusion as

one = 2.

But if I am required to give such simple functions a name it
is almost inevitable I have to use such a horrible name.
the alternative is to use bland names like "func" but what
advantage does the name give you anyway? I either call
all such one-liners "func" and then there is debug help
in the name or I will have to be sure that every function
somehow has a unique name. Having to track how far I am
in the range of func1, func2 accross the code seem very
cumbersome and not worth the while. Think of what may
happen if you start using different packages each with
there own func1, func2 range of functions.

--
Antoon Pardon

--
Antoon Pardon

[Ketil Malde]

al***@mac.com (Alex Martelli) writes:

But if we can agree to name every function except continuations I'll be
content

FWIW, I disagree:

A simple example, doubling each entry in a list:

map (*2) xs
vs. let double x = x*2 in map double xs

Here's another example, extracting all lines that contain at least one
word:

filter (not.null) . map words . lines

Note that I'm using the following anonymous functions:

not . null
filter (not . null)
map words
filter (not.null) . map words

Would it really improve anything if I named these? It seems
incredibly pedestrian, along the lines of requiring a comments for
every source line:

x++; /* increase x by one */
a[x] = ' '; /* insert a space in a at position x */

Sometimes the best documentation is the code itself. Sometimes the
best name for a function is the code itself.

-k
--
If I haven't seen further, it is by standing in the footprints of giants

[sross]

> I do wonder what would happen to Cells if I ever want to support

multiple threads. Or in a parallel processing environment.

AFAIK It should be fine.
In LW, SBCL and ACL all bindings of dynamic variables are thread-local.

Cheers,
Sean.

[Rob Warnock]

Ketil Malde <ke********@ii. uib.no> wrote:
+---------------
| Sometimes the best documentation is the code itself.
| Sometimes the best name for a function is the code itself.
+---------------

And there's no reason that an anonymous LAMBDA [even if compiled]
couldn't store its source code in the "name" slot for debugging
printouts [e.g., stack backtraces].
-Rob

-----
Rob Warnock <rp**@rpw3.or g>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 [phone]

[Boris Borcic]

Ken Tilton wrote:

"Now if you are like most
people, you think that means X. It does not."

As far as natural language and understanding are concerned, "to mean" means
conformity to what most people understand, Humpty Dumpties notwithstanding .

Cheers.