[Python-Dev] any support for a methodcaller HOF?
ncoghlan at gmail.com
Sat Feb 4 13:41:48 CET 2006
Eric Nieuwland wrote:
> Then how about nameless function/method definition:
> def (x):
> ... usual body ...
Hell no. If I want to write a real function, I already have perfectly good
syntax for that in the form of a def statement. I want to *increase* the
conceptual (and pedagogical) difference between deferred expressions and real
functions, not reduce it. There's a reason I try to use the term 'deferred
expression' for lambda rather than 'anonymous function'. Even if lambdas are
*implemented* as normal function objects, they're a conceptually different
beast as far as I'm concerned - a function is typically about factoring out a
piece of common code to be used in multiple places, while a lambda is about
defining *here* and *now* an operation that is to be carried out *elsewhere*
and possibly *later* (e.g., sorting and predicate arguments are defined at the
call site but executed in the function body, callbacks are defined when
registered but executed when the relevant event occurs).
> produces an unnamed method object
> def spam(x):
> is just
> spam = def (x):
Except that it wouldn't be - the name used in a def statement has special
status that a normal variable name does not (e.g. the function knows about its
real name, but nothing about the aliases given to it by assignment statements).
> while our beloved
> eggs(lambda x: x*x)
> would become
> eggs(def(x): return x*x)
I personally believe this fascination with "we want to be able to include a
suite inside an expression" has been a major contributor to Guido's irritation
with the whole concept of anonymous functions. That may just be me projecting
my own feelings though - every time I try to start a discussion about getting
a clean deferred expression syntax, at least one part of the thread will veer
off onto the topic of embedded suites. IMO, if what you want to do is complex
enough that you can't write it using a single expression, then giving it a
name and a docstring would probably make the code more comprehensible anyway.
Generator expressions allow a generator to be embedded only if it is simple
enough to be written using a single expression in the body of the loop. Lambda
does the same thing for functions, but for some reason people seem to love the
flexibility provided by genexps, while many think the exact same restriction
in lambda is a problem that needs "fixing". Maybe once PEP 308 has been
implemented, some of that griping will go away, as it will then be possible to
cleanly embed conditional logic inside an expression (and hence inside a lambda).
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev