[Python-3000] A plea for anonymous functions

Fredrik Lundh fredrik at pythonware.com
Thu Nov 16 08:33:50 CET 2006


Talin wrote:

> Javascript, for example, doesn't need special syntactical sugar for 
> generator expressions:
> 
>     /* Return a list of the square of numbers.
>       ('map' appears courtesy of Mochikit.js) */
> 
>     result = map( [1, 2, 3, 4], function (a) {
>        return a * a;
>     })
> 
> No, its not quite as concise as a generator expression, but it is far 
> more general in what it can do.

Are you sure you know what a generator expression is?  Mochikit's map is 
just a JavaScript version of Python's function with the same name; it 
takes an Array or an Array-like object, maps it though a function, and 
returns an Array.  Compare

     http://mochikit.com/doc/html/MochiKit/Base.html#fn-map

with

     http://effbot.org/pyref/map.htm

> Now, there are those who say "Just use a named function", but that 
> argument doesn't hold - because the *same* argument can be levied 
> against generator expressions, the 'with' statement, and a number of 
> other recent syntactical innovations in Python.

Oh, please: Generator expressions (which you might need to study a bit 
further) is generalization of list comprehensions (which is turn is 
syntactical sugar for a for-in statement); and the the "with" statement 
was added mostly because it's *not* very practical to wrap try/finally 
handlers in functions; see

     http://online.effbot.org/2006_10_01_archive.htm#with

for more on this.

> From my point of view, both 'with' and generator expressions are 
> limited, special-case solutions to a general problem - the desire to be 
> able to use and manipulate unnamed blocks of code as first-class 
> objects.

Python has two full block constructs: "for-in" (which has been in there 
from the start) and "with" (added in 2.5).  The "for-in" block construct 
is discussed here:

     http://online.effbot.org/2006_11_01_archive.htm#for

As I mention in a comment in the with-article, it's all about use cases: 
do 'for-in' blocks and 'with' blocks cover most of the use cases for 
which a full-blown callback isn't a conceptually cleaner thing to use 
anyway?

The current Python hypothesis is 'yes, they do'.

To prove that they don't, you *have* to provide use cases, and show how 
they would look and feel.  Hand-waving arguments and vague promises of 
"once you reach my level of sophistication, you'll understand" isn't 
good enough.

(And frankly, it would be *wonderful* if someone could come up with a 
new proposal that actually enabled Python programmers to do things they 
*cannot* do today, instead of just rehashing old "let's move the sofa 
over there" threads.  How about doing something along the lines of 
LINQ's "give me this expression as an AST so I can optimize it myself" 
model or looking at COmega's parallelization/synchronization stuff or 
digging deeper into how PJE's RuleDispatch could be fit into Python or 
stealing some cool idea from some functional research language that I 
haven't even heard of.  I want to get *new* things when I upgrade from 
2.X to 3.0, not just silly syntax tweaks that would only give me the 
ability to change two lines of Python code to one line of code plus a 
comment that explains what the heck that line is doing.  Let's do some 
*hard* stuff, for a change.)

</F>



More information about the Python-3000 mailing list