[Python-3000] A plea for anonymous functions

[Fredrik Lundh]

Talin wrote:

> The problem with providing use cases is that each one individually 
> doesn't carry much weight. When I do Javascript/AJAX programming, I use 
> anonymous functions quite a bit, as in the following example:
> 
>     do_command( 'get_synset_links', {}, function( response_data ) {
>        format_expanded( li.content, response_data.related )
>     })
> 
> 'do_command' calls a function on the server side via an async HTTP 
> request, and calls the callback when the data is ready. By using an 
> anonymous function as the callback, I can group the request for the data 
> and the use of that data together in a logical way.

Your specific example would probably be written:

     server.get_synset_links(
         lambda rec: format_expanded(li.content, rec.related)
     )

in today's Python, which I find a bit easier to read than your slightly 
bloated JavaScript example.

How do you handle errors, btw?

> Could I do the same thing using a named callback? Sure. Would it be as 
> easy to read and as clear?

Well, if you find that easy to read and clear, I suspect you're more of 
a JavaScript programmer than a Python programmer.  Here's how a more 
general form of the above would look in Python:

     response = (yield server.get_synset_links())
     format_expanded(li.content, response.related)

or

     def handle_response(record):
         format_expanded(li.content, response.related)
     server.get_synset_link(handle_response)

or perhaps

     with async server.get_synset_link() as response:
         format_expanded(li.content, response.related)

(all of which are shorter than your JavaScript example, by the way)

> But it doesn't matter, because no matter what cases I come up with, 
> someone will claim "You're just saving 2 lines of code".

No, I said that under your proposal, you're trading two lines of code 
that looks like Python for two (or three) lines of code that looks like 
something else.

 > The fact that it saves 2 lines of code in many different places in
 > my program can't easily be illustrated in an email message.

Well, this far, you haven't even been able to illustrate how your 
unspecified block syntax would have saved you a single line even in your 
three-line example.  That's not a good start, really.

> I would disagree with one bit: I think most of those things can be done 
> in Python today, they are just complicated and ugly under the current 
> syntax. As much as people decry 'syntactic sugar', I would argue that 
> those things you mentioned (even the AST example, although it's tricky) 
> really just need sugar to make them feasible and useful to ordinary 
> programmers, rather than any fundamental change to the execution model.

So show us some sugar, then.  After all, Python's design is driven by by 
an urge to simplify real usage patterns that's been observed in the 
wild, rather than theoretically-useful-for-everything-maybe language 
constructs that's been dreamed up in some laboratory.  And all the 
things I've mentioned *are* used in real code.

Also see the "Patterns are signs of weakness in programming languages" 
discussions:

    http://newbabe.pobox.com/~mjd/blog/prog/design-patterns.html

and note that Python's usually aiming for "(nearly) invisible", not 
"formal", in Norvig's taxonomy.

Also see the part about use cases for block constructs in my original 
post to this thread.

</F>