[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