a = b = 1 just syntactic sugar?

[Michael Chermside]

Ed:

I'll attempt to respond BRIEFLY to several of the points you have made:

> I think that the rule of 'anything that fits on one
> line' is such a simple rule; just as simple as 'any expression, but
> not a statement' and more powerful.

I disagree. There are quite a few places in Python where the
rules allow "insert any expression here". However, there are NO
places in Python that allow "insert here anything that fits on
one line". Having lambdas work the SAME way as all of the other
places that allow expressions, is a great simplification.

> I'm not trying to attack the distinction between expressions and
> statements.  I know better than to do that.  I am just asking, why is
> it that the body of an anonymous function cannot contain statements?

Specifically, because there are only two places in Python that can
contain statements... a python file, and a "suite" (the inside of
a def, an if, a while, etc.) In particular, notice that there's no
arbitrary nesting. Expressions can contain other expressions, and
thus they can nest arbitrarily deeply, and the parser (and the
reader of the code) need to follow the parentheses (and sometimes 
the precidence rules) to figure out what is intended. Now, that kind
of free nesting is a useful thing, but it is not ALWAYS useful, and
statements do NOT do the same thing.

Statements, instead have only restricted nesting. There are
certain statements (def, if, while, etc) that can contain suites
(and thus other statements), but these are delimited by newlines
and nesting, plus the end-of-line colon. (Exception: one-line
suites like "if x: return x".)

If you were a compiler, you might think "yeah, they're two separate
hierarchys, that nest but don't mix... but they COULD". But if
you're a human being, you don't see it this way. Humans pay LOTS
of attention to those newlines and indents. We read code "line-by-
line"... but more precisely, we tend to break things down to the
level of the individual statement, but then to grok the entire
statement as a chunk. (It's not the only level on which we read
code, but its an important one.) The highly-visible indentation
tells us "oh yes, this statement is indented, so it's still
within this function, which itself is within that class declaration
we saw back there".

People don't find Lisp to be quite so readable. And an important
part of the difficulty is that writing in pure syntax trees, while 
so wonderful when writing programs that modify code, makes it
difficult for readers of the code to find reasonable-sized "chunks"
so they can read the code chunk-by-chunk. Python statements serve
that purpose admirably.

So you see, separating statements and expressions is a design GOAL
of Python, one in keeping with its emphasis on readability over
programming "purity", and even (occasionally) over power. In this
case, lambdas are expressions, and thus can be contained by arbitrary
expressions in arbitrarily deep nestings. Therefore, it is IMPORTANT
that they not be permitted to contain statements. In fact, if
something about lambda made it NECESSARY that they contain 
expressions, then it would be better to just leave lambda out of
the language altogether! (After all, "def" is really not very hard
to type!)

Fortunately, that's not necessary. If we say that lambdas may contain
expressions, then they'll work fine for things like "lambda x: x + 2",
and "lambda x, y: x % (y,)", which is about the level of complexity
that's appropriate before the function is significant enough to
deserve a name of its own.

> So far people have mentioned that Python distinguishes between
> expressions and statements, which is a description of 'what' the
> language does, but they haven't really explained 'why' this means that
> an anonymous function definition, which is an expression, could not
> contain a one-line statement.

Does the above help? There's also the syntax problem (no good syntax
for allowing it), but what Terry already said on that subject is
better than what I could hope to add, so I'll simply point to his
excellent discussion of the subject from the point of view of Python's
grammer productions.

Ed... please note that we're not trying to attack you here. There are
good reasons why lambda isn't more powerful than it is, and someone
should explain them someplace. Hopefully, we're getting somewhere on
it in this thread.

-- Michael Chermside