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/

[Ben]

Ok, I'm sorry. This kind of discussions between two groups of people,
neither of who know the other person's language very well just wind me
up something chronic! It wasn't your post as such, just reading through
most of the thread in one go.

That will teach me to post while cross :). Sorry for any offence.

Anything that makes programming more fun is good, and I hope the Lisp
true way explodes into my head at some point.

Cheers,
Ben

[A. Rogowski]

al*****@yahoo.c om (Alex Martelli) writes:

Bill Atkins <NO**********@r pi.edu> wrote:
...

``allow ( as an ordinary single-character identifier'' as for the
unneded feature ``allow unnamed functions with all the flexibility of
named ones''.

Not so infeasible:

(let ((|bizarrely(na med()symbol| 3))
(+ |bizarrely(name d()symbol| 4))

;; => 7

Read again what I wrote: I very specifically said "ordinary
*single-character* identifier" (as opposed to "one of many characters
inside a multi-character identifier"). Why do you think I said
otherwise, when you just quoted what I had written? (Even just a
_leading_ ( at the start of an identifier may be problematic -- and just
as trivial as having to give names to functions, of course, see below).

bah...

[1]> (setq rtbl (copy-readtable))
#<READTABLE #x203A0F6D>
[2]> (set-syntax-from-char #\{ #\()
T
[3]> (set-syntax-from-char #\( #\a)
T
[4]> {defun ( {a) {1+ a))
(
[5]> {( 1)
2
[6]> {( 4)
5
[7]> {setq *readtable* rtbl)
#<READTABLE #x203A0F6D>
[8]> (1+ 1)
2

With readtable and reader macros you can change the syntax as you
wish.

ajr.

[Ken Tilton]

Ben wrote:

This kind of discussions between two groups of people,
neither of who know the other person's language very well just wind me
up something chronic!
I must say, it is pretty funny how a flamewar turned into a pretty
interesting SoC project.
Anything that makes programming more fun is good, and I hope the Lisp
true way explodes into my head at some point.

Here is an excerpt of an excerpt from famous Gears demo. I notice it
really makes concrete what Lispniks are talking about in re macros and
multi-line lambda (pity about the formatting):

(defmodel gears-demo (window)
((gear-ct :initform (c-in 1) :accessor gear-ct :initarg :gear-ct))
(:default-initargs
:title$ "Rotating Gear Widget Test"
:kids (c? (the-kids
(mk-stack (:packing (c?pack-self))
(mk-row ()
(mk-button-ex (" Add " (incf (gear-ct .tkw))))
(mk-button-ex ("Remove" (when (plusp (gear-ct .tkw))
(decf (gear-ct .tkw)))))
(mk-entry :id :vtime
:md-value (c-in "10")))
(make-instance 'gears
:fm-parent *parent*
:width 400 :height 400
:timer-interval (max 1
(or (parse-integer (fm^v :vtime))
:junk-allowed t)
0)))))))

Don't worry, Lispniks cannot read that either. It is a delarative
construction of a hierarchical GUI. That is such a common task, that I
have rolled up a bunch of GUI-building macrology so that just the stuff
specific to this GUI gets typed in. Since the Gears widget is a custom
widget I have no macrology for that, and the wiring shows in the
expression ":fm-parent *parent*" (which itself leverages Lisp special
variables).

And no, I cannot remember all my macrology. I can certainly read it and
easily modify my GUI, because all the wiring is hidden, but if I have to
build a new GUI I cut and paste from other GUIs.

Let's look at just one form, which I believe destroys Alex's whole case
for naming every lambda:

(mk-button-ex ("Remove" (when (plusp (gear-ct .tkw))
(decf (gear-ct .tkw)))))

"mk-button-ex" (a) makes fun of MS$ naming standards and (b) expands to:

(make-instance 'button
:fm-parent *parent*
:text "remove"
:on-command (c? (lambda (self)
(when (plusp (gear-ct .tkw))
(decf (gear-ct .tkw))))))

The above is what one really needs to write to stick something in my GUI
framework, but who wants to look at all of that when most of it is
boilerplate? I need ":fm-parent *parent*" on every label and widget
because of some internals requirements, I just do not want to look at it
or have to remember to code it all the time (the latter not being a huge
problem because I really am cutting/pasting when I build a new GUI).

Is mk-button-ex some mysterious new language construct that will make
multi-programmer projects collapse in a heap of programmer-specific
constructs inscrutable to anyone else on the team?

(a) mk-button-ex kinda tells you (1) it makes a button and (2) no, this
is not part of Common Lisp, so where is the confusion?

(b) control-alt-. in my IDE shows me:

(defmacro mk-button-ex ((text command) &rest initargs)
`(make-instance 'button
:fm-parent *parent*
:text ,text
:on-command (c? (lambda (self)
(declare (ignorable self))
,command))
,@initargs))

Looks a lot like the expansion, right? That is really important in
making macrology easy. Once one has mastered the syntax (` , @), writing
a macro gets as natural as writing out the code. (In case you are
wondering, in my little example I did not need any other customizations
on the button, so it is hard to make out what the initargs are doign up
there. here is how they would work (also getting a little fancier by
actually disabling the "Remove" button, not just making it do nothing
when pressed, if the gear count is zero):

(mk-button-ex ("Remove" (decf (gear-ct .tkw)))
:fore-color 'red ;; Tcl/Tk will understand
:enabled (c? (plusp (gear-ct .tkw))))

becomes:

(make-instance 'button
:fm-parent *parent*
:text "remove"
:on-command (c? (lambda (self)
(decf (gear-ct .tkw))))
:fore-color 'red
:enabled (c? (plusp (gear-ct .tkw))))

[ps. Do not try that at home, i invented the enabled thing. It really
should be the Tk syntax, which I forget.]

ie, I created mk-button-ex because, jeez, every button I put in a GUI I
/know/ needs its own label and its own command (and the parent thing),
but there are other options, too. They have to be supported if the macro
is to get used all the time (we want that), but I do not want to make
them positional arguments without identifying keywords, because then the
code would be unreadable as well as unwritable (from memory).

Needless to say, there is more macrology in the expansion. One bit of
fun is .tkw. Background: in the GUIs I roll, a widget always knows its
parent. I guess you noticed. Anyway, because of that, a rule can kick
off code to navigate to any other widget and get information, ie, it
pretty much has global scope and that means power. Now one place a rule
will often look is up the hierarchy, say to a containing radio group for
a radio button. So the first thing I wrote was:

(upper self radio-group) -> (container-typed self 'radio-group)

Hmmph. I am /always/ upper-ing off self, I am surprised I have not
written a macro so I can just do (^upper radio-group). Soon. But since I
often look to the containing window in rules, I was looking for
something insanely short, shorter than even parentheses would allow,
like ".tkw":

(define-symbol-macro .tkw (nearest self window))

Nearest is like "upper" except that it is inclusive of the starting
point of the search (and, no, I am not happy with the name <g>).

And so it goes with Lisp macros. All the tedious boilerplate is hiiden,
in ways that cannot be done with functions. Oh, I skipped that point.
Look again at how the command (decf (gear-ct .tkw)) gets spliced into
the lambda form as so much source code:

From:
(mk-button-ex ("Remove" (decf (gear-ct .tkw))))

To:
(make-instance 'button
:fm-parent *parent*
:text "remove"
:on-command (c? (lambda (self)
(decf (gear-ct .tkw))))))

If mk-button-ex were a function, Lisp would try to evaluate

(decf (gear-ct .tkw))

which would be pretty sad because the "self" in there would not even
exist yet (the form is an /input/ to make-instance of what will become
"self" by the time the macro expansion code runs.

Which brings us to the idea of every multi-line lambda needing a name.
Does this:

(lambda (self)
(when (plusp (gear-ct .tkw))
(decf (gear-ct .tkw)))

Not sure what the Python would be, but maybe:

lambda (self):
if nearest(self,'w indow').gear_ct > 0:
nearest(self,'w indow').gear_ct = \
nearest(self,'w indow').gear_ct - 1

Does that need a name?

kenny

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

[Lasse Rasinen]

Ken Tilton <ke*******@gmai l.com> writes:

If you want to insist on how perfect your code is, please go find
ltktest-cells-inside.lisp in the source you downloaded and read the long
comment detailing the requirements I have identified for "data integrity".
Then (a) tell me how your code fails at integrity, (b) fix it, and (c)
tell me again how easy Cells is. :)
Found it and read it; it was most enlightening. I claim my system fulfills
the first three requirements(*) , while most likely failing gloriously on
the two last ones.

I'll postpone (b) while I've had a chance to think it over(**), but in the
face of the evidence I'm willing to admit my earlier work estimates (which
should have had a smiley next to them anyway ;-) were in error.

I won't admit to destroying Moscow, though. See (*).

(*) All values depending on the changed cell are marked as invalid before
anything else is done; trying to access an invalid value forces a
recalculation which also marks the cell as valid again, and so on
recursively down to cells that have already converged to a proper value.

Setting input cells in callbacks will f*** that up, though.

(**) Which probably doesn't occur until July or something ;(

[Decorator example]

Wow. I thought Python did not have macros.

Calling decorators macros is an insult to CL macros ;-)
All they do is make it a bit more convinent to apply transformations to
functions, or as the abstract in the original spec[1] says:

The current method for transforming functions and methods (for instance,
declaring them as a class or static method) is awkward and can lead to
code that is difficult to understand. Ideally, these transformations
should be made at the same point in the code where the declaration
itself is made.
This project is looking better all the time. Thx.

In that case I have something else you might like: The "with" Statement[2]

From the abstract:
This PEP adds a new statement "with" to the Python language to make
it possible to factor out standard uses of try/finally statements.

In practice one can use it implement some of the with-macros in a pretty
straightforward manner, especially those that are expanded into
(call-with-* (lambda () ,@body)). I believe the previously advertised
with-integrity macro could also be made to work in a satisfying manner.

To quote from the examples:

2. A template for opening a file that ensures the file is closed
when the block is left:

@contextmanager
def opened(filename , mode="r"):
f = open(filename, mode)
try:
yield f
finally:
f.close()

Used as follows:

with opened("/etc/passwd") as f:
for line in f:
print line.rstrip()

Does that last part look familiar to you?)

The problem with this is that this is Python 2.5 syntax, which currently
appears to be planned for release in late August, a bit late for SoC.
Alpha(*) versions are available, so if you want to take a chance and live
on the bleeding edge, you can probably gain from it.

(*) I don't keep a very close eye on the alpha releases, which is why I
didn't remember this yesterday. I like my programming tools steady
and stable ;-)

[1] http://www.python.org/dev/peps/pep-0318/#abstract
[2] http://www.python.org/dev/peps/pep-0343/
--
Lasse Rasinen
lr******@iki.fi

[Ken Tilton]

Lasse Rasinen wrote:

Ken Tilton <ke*******@gmai l.com> writes:

If you want to insist on how perfect your code is, please go find
ltktest-cells-inside.lisp in the source you downloaded and read the long
comment detailing the requirements I have identified for "data integrity".
Then (a) tell me how your code fails at integrity, (b) fix it, and (c)
tell me again how easy Cells is. :)

Found it and read it; it was most enlightening. I claim my system fulfills
the first three requirements(*) , while most likely failing gloriously on
the two last ones.

<sigh>

From #1: "recompute all and (for efficiency) only state computed off X
(directly or indirectly through some intermediate datapoint)"

Bzzzt! Another 47hrs, directions from a mentor, and a reference
implementation and you /still/ do not even understand the requirements,
let alone have a working port. The good news is that it is not an
integrity requirement that is being missed, it is the efficiency
requirement I snuck in there. The bad news is, see below.

Want to find the efficiency shortcoming yourself, or should I tell you?
You are entitled to the latter given the rules of the game (simulating a
pythonista student making off with five thousand undeserved dollars). :)

I'll postpone (b) while I've had a chance to think it over(**), but in the
face of the evidence I'm willing to admit my earlier work estimates (which
should have had a smiley next to them anyway ;-) were in error.
Aw, shucks, then I will admit that, before today, I never actually
looked at your code. :)

Well, I followed the URL and glanced at it, but I missed the use of the
timestamp. Speaking of which, Holy Granularity, Batman! You use
Time.time() to determine currency of a computation?!:

"time()
Return the time as a floating point number expressed in seconds
since the epoch, in UTC. Note that even though the time is always
returned as a floating point number, not all systems provide time with a
better precision than 1 second."

One /second/?!!!!! Exactly how slow is Python? I know you guys love that
issue as much as Lispniks. In un-compiled Lisp:

CTK(4): (loop repeat 2 do (print (get-internal-real-time)))
464033837
464033837

And you have no idea how slow PRINT is. btw, I thought Python was
portable. What is with the Time class and "not all systems..."? Check
out the Lisp:

(defun zoom ()
(loop with start = (get-internal-real-time)
while (= start (get-internal-real-time))
count 1 into cities-destroyed
finally (format t "~a cities destroyed in 1/~a of a second"
cities-destroyed internal-time-units-per-second)))

internal-time-units-per-second is (from the standard):

"Constant Value:
A positive integer, the magnitude of which is
implementation-dependent. "

So we vary, too, but my Lisp has to tell me so I can normalize. Anyway,
running that repeatedly I get pretty wild variation. My high score is:

CTK(18): 11637 cities destroyed in 1/1000 of a second

My low was under a thousand! I guess I have to wait until we cross a
millisecond boundary:

(defun zoom ()
(symbol-macrolet ((now (get-internal-real-time)))
(loop with start = (loop for mid = now
while (= mid now)
finally (return now))
while (= start now)
count 1 into cities-destroyed
finally (format t "~a cities destroyed in 1/~a of a second"
cities-destroyed
internal-time-units-per-second))))

Ok, now I am consistently taking out about 11.5k Russian cities. And you
need to fix your system.

Just use a counter -- does Python have bignums? if not, you'll have to
worry about wrapping. (the sound you hear is a project schedule
slipping. <g>)

I won't admit to destroying Moscow, though. See (*).
Sorry, you actually /have/ violated the data integrity requirement. You
confess below to missing this one:

"a corollary: should a client observer SETF a datapoint Y, all the above
must happen with values current with not just X, but also with the value
of Y /prior/ to the change to Y."

Well, how can you claim integrity when some values do not get
recalculated until the world has moved on to state N+2, if you will?
State N+1 had the information that headed off the launch.

Bye bye, Kremlin.

The easiest way to construct such a scenario would be with an ephemeral
cell. As you know... oops. Maybe you do not. Well, spreadsheets are
kinda steady state in orientation. Given a world of other values, this
is what my value should be. But what about events? You have been using
your version of PyCells in real-world applications for a while... oops.
No you have not. Well, when you start trying to handle events from an
event loop, you will discover a need to model events. (Trust your
mentor.) You need a slot that can be assigned normally, propagate
according to the above rules and regulations, and then revert to a null
state but /not/ as a state change -- neither propagating nor
observer-notifying.

They are, like, ephemeral, aka, "fleeting".

Now as I said, I got away with such holes for /years/ in all sorts of
hairy applications of Cells before finally, well, falling down those
holes, but it does happen so the holes are really worth filling in.

And wait till you see what this does to your algorithm. :) I was even
tempted to ban observer writebacks, if you will, but I think someday I
will write an application driven by such things, periodically calling
Tcl_DoOneEvent to keep in touch with the outside world.

Which means we cannot propagate on the stack, as your system would.
<slip...slip... slip>

(*) All values depending on the changed cell are marked as invalid before
anything else is done; trying to access an invalid value forces a
recalculation which also marks the cell as valid again, and so on
recursively down to cells that have already converged to a proper value.

Setting input cells in callbacks will f*** that up, though.

(**) Which probably doesn't occur until July or something ;(

[Decorator example]
Wow. I thought Python did not have macros.

Calling decorators macros is an insult to CL macros ;-)
All they do is make it a bit more convinent to apply transformations to
functions, or as the abstract in the original spec[1] says:

The current method for transforming functions and methods (for instance,
declaring them as a class or static method) is awkward and can lead to
code that is difficult to understand. Ideally, these transformations
should be made at the same point in the code where the declaration
itself is made.

This project is looking better all the time. Thx.

In that case I have something else you might like: The "with" Statement[2]

I had high hopes for that when I saw it, then was not sure. The good
news is that Serious Pythonistas will be doing this, not me. I will just
help them grok the requirements (and hope Ryan is taking notes <g>).

From the abstract:
This PEP adds a new statement "with" to the Python language to make
it possible to factor out standard uses of try/finally statements.

In practice one can use it implement some of the with-macros in a pretty
straightforward manner, especially those that are expanded into
(call-with-* (lambda () ,@body)). I believe the previously advertised
with-integrity macro could also be made to work in a satisfying manner.

To quote from the examples:

2. A template for opening a file that ensures the file is closed
when the block is left:

@contextmanager
def opened(filename , mode="r"):
f = open(filename, mode)
try:
yield f
finally:
f.close()

Used as follows:

with opened("/etc/passwd") as f:
for line in f:
print line.rstrip()

Does that last part look familiar to you?)

The problem with this is that this is Python 2.5 syntax, which currently
appears to be planned for release in late August, a bit late for SoC.
Alpha(*) versions are available, so if you want to take a chance and live
on the bleeding edge, you can probably gain from it.

That is up to the Pythonistas. As a rule, if there is advantage to be
had, I go with the bleeding edge until it proves to me it is unusable.

Thx for the heads up.

Nice job on the code, btw. A lot better than my first efforts.

kenny

--
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.

[Kay Schluehr]

Ken Tilton wrote:

Is there any experiemntal macro package out there for Python? Maybe a
preprocessor, at least? Or are there ways to actually hack Python to
extend the syntax?

Yes. I've just released EasyExtend that does this kind of job:

http://www.fiber-space.de/EasyExtend/doc/EE.html

It fits quite nice with Python and is conceptually simple, safe and
reasonably fast. Using EasyExtend PyCells could be made an own language
( including Python ) defined in a Python package ( i.e. no C-code and
complex build process is required ). I would be interested in user
experience. I wouldn't consider EE as "experiment al" i.e. open for
severe changes. It still lacks some comfort but it also improves
gradually in this respect.

[Michele Simionato]

Kay Schluehr wrote:

http://www.fiber-space.de/EasyExtend/doc/EE.html
Well, I have not read that page yet, but the name "fiber space" reminds
me of old
memories, when I was doing less prosaic things than now. Old times ..
;)

Michele Simionato
It fits quite nice with Python and is conceptually simple, safe and
reasonably fast. Using EasyExtend PyCells could be made an own language
( including Python ) defined in a Python package ( i.e. no C-code and
complex build process is required ). I would be interested in user
experience. I wouldn't consider EE as "experiment al" i.e. open for
severe changes. It still lacks some comfort but it also improves
gradually in this respect.

[Kay Schluehr]

Michele Simionato wrote:

Kay Schluehr wrote:

http://www.fiber-space.de/EasyExtend/doc/EE.html

Well, I have not read that page yet, but the name "fiber space" reminds
me of old
memories, when I was doing less prosaic things than now. Old times ..
;)

Michele Simionato

But I guess that time this stuff was taught to you as "fiber bundles",
right? Oh, yes. Old times ;)

Well, besides the cute rhyme on "cyberspace " I had this analogy in mind
and that's why I called the extension languages "fibers". The
association is "fibers over a base space" or a base language as in this
case. The terms are not used strictly of course. I could not even say
what triviality could be in this context. But I still seek for an
acceptable glue mechanism which is beyond the scope of the current
first release :)

Kay