[Python-ideas] Ruby-style Blocks in Python Idea
Terry Reedy
tjreedy at udel.edu
Tue Mar 10 21:15:01 CET 2009
Guido van Rossum wrote:
> 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.
Initializing such structures is one of the use cases I intended under
'where appropriate'. Adding more powerful expressions, like
comprehensions (and g.e's) that do not break Python's basic syntactic
model of mixed expressions and indented statements has added to the
convenience.
> 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).
The convenience is from having function expressions. If the expression
syntax allowed the optional attachment of a name, it would be just as
convenient. In some cases, I am sure people would find it even more
convenient if they could add in a name, especially when there is nothing
else in the structure to serve as a substitute.
'Anonymous' is a different concept from 'expression-defined' despite the
tendency to conflate the two.
Terry Jan Reedy
More information about the Python-ideas
mailing list