Multi-line lambda proposal.

[Antoon Pardon]

Op 2006-05-09, Scott David Daniels schreef <scott.daniels at acm.org>:
> Kaz Kylheku wrote:
>> I've been reading the recent cross-posted flamewar, and read Guido's
>> article where he posits that embedding multi-line lambdas in
>> expressions is an unsolvable puzzle.
>> 
>> So for the last 15 minutes I applied myself to this problem and come up
>> with this off-the-wall proposal for you people. Perhaps this idea has
>> been proposed before, I don't know.
>
> Well, ask yourself, what is the complexity, and what is the
> benefit.  You are solving a problem that causes very little
> pain, and introducing a mechanism that is likely to inspire
> thousands of lines of unmaintainable code.  Essentially, a
> rule that says, "if it is not a simple expression, pick a
> name for it" is just not a bad idea.

Well I guess that seems a good rule of thumb.

The problem is that even a simple "expression" sometimes requires
a name in python or turns it into a more complex function. 

Take the following example:

def incr_cnt_by_one(obj):
  obj.cnt += 1

IMO that is simple enough not to require a name. But it is almost
impossible to put this behaviour in a lambda. If you do you end
up with something like:

  lambda obj: setattr(obj, 'cnt', obj.cnt + 1)


So maybe a general lambda is indeed impossible in python. A pity
IMO, but not that big a deal. 

But the limit that certain statements are not expressions makes
that you sometimes require a name even with some simple stuff
like:

  def Raise_ValueError():
    raise ValueError

  RegisterErrorFunction(Raise_ValueError)

What would be so horrible if we could do the following:

  RegisterErrorFunction(lambda: raise ValueError)

or

  treat_all(aList, lambda obj: obj.cnt += 1)

-- 
Antoon Pardon