[Python-ideas] Ruby-style Blocks in Python Idea

Guido van Rossum guido at python.org
Tue Mar 10 00:55:18 CET 2009


On Mon, Mar 9, 2009 at 4:09 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Like many other Pythonistas I recognize that that an uninformative stock
> name of '<lambda>' is defective relative to an informative name that points
> back to readable code.  What I dislike is the anonymity-cult claim that the
> defect is a virtue.
>
> Since I routinely use standard names 'f' and 'g' (from math) to name
> functions whose name I do not care about, I am baffled (and annoyed) by
> (repeated) claims such as "Having to name a one-off function adds additional
> cognitive overload to a developer." (Tav).  Golly gee, if one cannot decide
> on standard one-char name, how can he manage the rest of Python?
>
> (I also, like others, routinely use 'C' for class and 'c' for C instance.
>  What next?  A demand for anonymous classes? Whoops, I just learned that
> Java has those.)
>
> But I have no problem with the use of lambda expressions as a convenience,
> where appropriate.

Andrew Koening once gave me a good use case where lambdas are really a
lot more convenient than named functions. He was initializing a large
data structure that was used by an interpreter for some language. It
was a single expression (probably a list of tuples or a dict). Each
record contained various bits of information (e.g. the operator symbol
and its precedence and associativity) as well as a function (almost
always a very simple lambda) that implemented it. Since this table was
100s of records long, it would have been pretty inconvenient to first
have to define 100s of small one-line functions and give them names,
only to reference them once in the initializer.

This use case doesn't have a nice equivalent without anonymous
functions (though I'm sure that if there really was no other way it
could be done, e.g. using registration=style decorators).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-ideas mailing list