Multi-line lambda proposal.

[Kaz Kylheku]

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.

The solutions I have seen all assume that the lambda must be completely
inlined within the expression: the expression is interrupted by the
lambda, which is then completely specified (arguments and body) and the
expression somehow continues (and this is where syntactic problems
occur, giving rise to un-Python-like repugnancies).

But suppose that the expression and the multi-line lambda body are
reordered? That is to say, the expression is written normally, and the
mlambda expressions in it serve as /markers/ indicating that body
material follows. This results in the most Python-like solution.

Suppose lambda() occurs without a colon

a = lambda(x, y), lambda(s, t), lambda(u, w): u + w
statement1
statement2
lambda:
statement3
statement4

The first two lambdas do not have a colon after them. This means that
they have multi-line bodies which follow this statement, and there must
be as many bodies as there are lambdas. The third lambda is a regular
one-expression lambda, entirely written right there.

The bodies are made up of the statements which follow. If there is only
one body, it's simply the indented material. If there are two or more
lambdas in the expression, additional bodies are required, introduced
by lambda: statements, which are at the same indentation level as the
expression which contains the lambda markers.

Of course, the bodies have their respective lambda parameters in scope.
So statement1 and statement2 have access to x and y, and statement3 and
statement4 have access to s and t.

Problem solved, with no Python repugnancies.

The way you can embed indented material in an expression is by not
physically embedding it.

If you want to be completely anally retentive, you can require that the
expression which has lambda bodies after it has to be terminated by a
colon:

a = lambda(x, y), lambda(s, t), lambda(u, w): u + w:
statement1
statement2
lambda:
statement3
statement4

If we take out the last two lambdas, this reduces to:

a = lambda(x, y):
statement1
statement2

Here, the colon terminates the lambda-containing statement. It is not
the colon which introduces the body of a one-expression lambda. E.g.:

a = lambda(x, y): x + y

a = lambda(x, y):
return x + y

The two are disambiguated by what follows. You get the picture.

More examples: lambda defined in a function call argument

a = foo(lambda (x, y)):
return x + y

Confusing? Not if you read it properly. "A lambda function is
constructed with arguments x, y and passed to foo, and the result is
assigned to a. Oh, and by the way, the body of the
lambda is: return x + y."

[Scott David Daniels]

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.

--Scott David Daniels
sc***********@a cm.org

[Leif K-Brooks]

Kaz Kylheku wrote:

But suppose that the expression and the multi-line lambda body are
reordered? That is to say, the expression is written normally, and the
mlambda expressions in it serve as /markers/ indicating that body
material follows. This results in the most Python-like solution.

I think your proposal is good, but it might be more easily understood if
we gave names to the lambdas, so that they could be easily picked out in
the source code. It could look something like this:

func(lambda foo):
foo:
print "Foo!"

Come to think of it, maybe we could put the lambdas before the statement
they're used in instead of in front of it. That could look something
like this:

lambda foo:
print "Foo!"
func(lambda foo)

Then again, it would probably be simpler to reuse an existing
block-starting keyword for the purpose. Maybe something like this?

def foo():
print "Foo!"
func(foo)

[Sybren Stuvel]

Kaz Kylheku enlightened us with:

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.
[...]
a = lambda(x, y), lambda(s, t), lambda(u, w): u + w
statement1
statement2
lambda:
statement3
statement4
I think it's a very ugly solution. If you need multiple lines in your
lambda, use an inner function. If you need a couple of single-line
lambdas and use them in a multi-line expression, assign them to a name
and use that name in their stead.
a = lambda(x, y):
return x + y
And what's the advantage of that above this?

def a(x, y):
return x + y
More examples: lambda defined in a function call argument

a = foo(lambda (x, y)):
return x + y

Confusing? Not if you read it properly. "A lambda function is
constructed with arguments x, y and passed to foo, and the result is
assigned to a. Oh, and by the way, the body of the
lambda is: return x + y."

I think it's very, very ugly. Use inner functions for that. They are a
much cleaner solution than this.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Antoon Pardon]

Op 2006-05-09, Scott David Daniels schreef <sc***********@ 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_ValueErro r():
raise ValueError

RegisterErrorFu nction(Raise_Va lueError)

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

RegisterErrorFu nction(lambda: raise ValueError)

or

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

--
Antoon Pardon

[Kaz Kylheku]

Kaz Kylheku wrote:

But suppose that the expression and the multi-line lambda body are
reordered? That is to say, the expression is written normally, and the
mlambda expressions in it serve as /markers/ indicating that body
material follows. This results in the most Python-like solution.

Unfortunately, while this idea has intuitive appeal, it leaves some
problems to solve; namely, lambdas that occur in expressions embedded
within statement syntax which has body material of its own. For
instance

# lambda defined and immediately called here
if lambda(x)(4) < 0:
print "a"
elif y = 4:
print "b"
else:
print "foo"

Where to stick the lambda body? It's not hard to come up with
straightforward answers, except that they are not particularly
appealing. One rule might be that the lambda bodies have to be placed
immediately after the statement body material, set off by the lambda:
thing. In the case of if/elif/else, they have to be placed behind the
closest suite that follows the expression in the syntax of the
statement:

if lambda(x)(4) < 0:
print "a"
lambda:
return x + 1
elif y = 4:
print "b"
else:
print "foo"

The overall rule is simple and uniform: each suite can have lambda:
clauses. These have to match lambda() occurences in the expression (or
expression list) immediately to the left in the same grammar
production.

On the other hand, some people might find this compromise more
attractive: simply do not allow multi-line lambdas in compound
statements.

[DH]

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.

To say that multi-line lambda is an unsolvable problem is completely
absurd. Furthermore it has already been solved.
http://wiki.python.org/moin/Alternat...bc7ba581dec6fa
So I agree with you, but I doubt you'll have any luck getting your
proposal or any other multiline lambda proposal accepted into python
anytime soon.

[Carl Banks]

DH wrote:

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.
To say that multi-line lambda is an unsolvable problem is completely
absurd.

Note that the "solution" is understood to entail the BDFL stamp of
approval.

Furthermore it has already been solved. http://wiki.python.org/moin/Alternat...bc7ba581dec6fa

Meh. I think the syntax you linked to would result in gobs of ugly and
unreadable code. I like how the examples are always part of relatively
simple statements ("Look, it's readable!"). Try citing examples of
these statements at work in if conditions, generator expressions, as
default arguments to functions, multiple times in the same statement.
Try showing what they look like nested. The "readable" example would
turn into ASCII vomit.

Probably the day it makes it into Python is the day Python jumps the
shark.
Carl Banks

[yairchu]

multi-line lambdas, had it been added to python a long time ago, would
had reduced a lot of complexity in the language.
for example - with multi-line lambdas - decorators are unneccesary.
just give the multi-line lambda as an argument to a function - no need
for special syntax..
the alternative decorators would also be simpler.
currently when you want to create a "decorator-that-accepts-additional-
arguments" you gotta make a funtion that gets those
additional-arguments and returns a function that will be the decorator.

[Antoon Pardon]

Op 2006-05-10, ya*****@gmail.c om schreef <ya*****@gmail. com>:

multi-line lambdas, had it been added to python a long time ago, would
had reduced a lot of complexity in the language.
for example - with multi-line lambdas - decorators are unneccesary.
I don't like the words neccesary or unneccesary in these discussions,
because they rarely add anything. For instances decorators are
unneccesary in python now, even without multi-line lambdas.

There is nothing you can do with decorators that you can't do
without.
just give the multi-line lambda as an argument to a function - no need
for special syntax..
There is no need for special syntax. The decorators are just syntactic
sugar to do something that was already possible before.
the alternative decorators would also be simpler.
currently when you want to create a "decorator-that-accepts-additional-
arguments" you gotta make a funtion that gets those
additional-arguments and returns a function that will be the decorator.

Could you give me an example. Suppose I have the following:

def arg_range(inf, sup):

def check(f):

def call(arg):
if inf <= arg <= sup:
return f(arg)
else:
raise ValueError

return call

return check

@arg_range(3, 12)
def func(arg):
return arg

How would this look simpler with multi-line lambda's?

--
Antoon Pardon