What can you do in LISP that you can't do in Python

[James_Althoff at i2.com]

Alex Martelli wrote:
><James_Althoff at i2.com> wrote in message
>news:mailman.990565593.9251.python-list at python.org...
>    ...
>> def doValidation():
>>     queryForm.validate()
>>     . . .
>>
>> def execQuery():
>>     queryForm.execQuery()
>>     . . .
>>
>> def doQuery():
>>     window.showStatusDuring(
>>         msg="Validating Query Form ...",
>>         function=doValidation())
>
>I suspect you don't want the parentheses after doValidation:
>you're passing the function, not calling it.

Right. The parens in "function=doValidation()" were not supposed to be
there.  Thanks.

<snip>

>So, in all, I might recode (while admitting there ARE
>still differences!) as:
>
>def doQuery():
>    def doValidation():
>        queryForm.validate()
>        ...
>    window.showStatusDuring("Validating Query Form", doValidation)
>    def execQuery():
>        queryForm.execQuery()
>        ...
>    window.showStatusDuring("Getting Results", execQuery)
>
>window.showBusyCursorDuring(doQuery)
>
>The def-before-you-pass-it need may be best met by defining
>JUST-before-you-pass-it.
>
>
>Alex

I agree that this version is good.  It does put the def right before its
use in the outside call and for both inside calls as well.  Even this
version, though (I believe), illustrates the point that (for me, at least)
the "named-block-before-use" approach doesn't have quite the same kind of
"top-to-bottom, linear flow" (when I read it) as an
"unnamed-in-place-definition" approach could have -- if one existed :-).
And that the "ahead-of-use" definition versus "in place" definition issue
is somewhat of a corollary to the "named" versus "unnamed" issue.

Jim