Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)

[Rustom Mody]

On Monday, March 24, 2014 7:34:59 PM UTC+5:30, Steven D'Aprano wrote:
> On Mon, 24 Mar 2014 22:49:38 +1100, Chris Angelico wrote:

> > wrote:

> >> You never *need* (Python's) lambda for anything. Inner functions are
> >> more capable and almost always more readable. It doesn't hurt to have
> >> lambda, but I don't find any use for it, either.

> Marko has missed an obvious use: lambda is the *only* solution when you 
> need a function embedded in an expression. You simply cannot do so 
> otherwise. It is truly astonishing that two people here who are such keen 
> supporters of functional programming, Marko and Mark Harris, are so 
> dismissive of lambda, and so forced to write declarative code using def.

> > They're often not more readable. A lot of people seem to equate
> > "verbose" with "readable", possibly by faulty extrapolation from
> > unreadably crunched code with one-letter variables and no line breaks.
> > But which of these is truly more readable?
> > squares = []
> > for n in range(30):
> >     squares.append(n * n)
> > squares = [n * n for n in range(30)]

> Readable for whom?

> List comprehension syntax is often completely obscure to beginners. A 
> beginner would say that the explicit for-loop is more readable.

> Actually, a *real* beginner, whose main programming experience before 
> Python was Pascal, would probably even say that the first example was an 
> unreadable mess. What's range(30)? What's this ".append" business? What 
> does [] mean? I know this because I was this beginner, once. The first 
> few times I tried reading Python code, I couldn't make head or tail of 
> it. "for" I recognised, because it was the same keyword as Pascal and 
> Hypertalk use. Pretty much everything else might as well have been 
> Bulgarian.

> This was before the public internet, there was no Google, no tutorials I 
> could look up. It was only after a colleague convinced me that it would 
> be a good language to learn that I bought an actual dead tree book and 
> sat down and learned how to read Python.

> I think that Python's reputation of being "executable pseudo-code" is 
> sometimes harmful. It fools people into thinking that unless Aunt Tilly 
> can understand a language feature, it's somehow a failure. Hence the 
> arguments by Mark against lambda.

> http://www.catb.org/jargon/html/A/Aunt-Tillie.html

> But nobody expects Aunt Tilly to read Scheme or C++ or Go without at 
> least a bit of learning -- or even Esperanto or French or Latin. You 
> still need to learn the syntax and the vocabulary, and have some idea of 
> the basic concepts. The same applies to Python. The learning curve may be 
> more gentle, but there is still a learning curve. And that is perfectly 
> fine.

Ok so far

> So while I agree with you that, to a moderately fluent Python speaker, 
> not a beginner but not an expert either, the list comprehension is more 
> readable, for a beginner (one who has a basic Python vocab but isn't 
> fluent yet) the for-loop will probably be more readable.

And now I wonder...
The case you are wanting to make and the case you are ending up making
seem to be opposite: 

If it is so as you say that for "the beginner (one who has a basic 
Python vocab but isn't fluent yet)"
the for-loop is more readable than the for-in-compr
it then suggests that those more experienced taking/helping the
beginners at 0 to the stage of "basic vocab-but-not-yet fluent" are
choosing a sub-optimal route.

Remember that you started by reminding that for an absolute beginner,
everything is 'Bulgarian' not just list comprehensions.

Then how come some things become accessible faster than others?
It may be that those things are actually easier (in some objective sense)
But it may also reveal a prejudice of the teachers.

As for the other argument -- python lambda is BAD -- Ive currently run out of pepper for sprinkling on these flames :-)
I'll just make a few points:

1. Miranda the predecessor of Haskell had no lambda.
Local defs + curried convention + operator sections was considered more than 
sufficient for functional programming

2. Lisp was the originator of lambda (in programming languages) and it screwed up the semantics so badly that
 a. It had to be corrected at high cost 25 years later -- aka scheme and common lisp
 b. Some doyens of functional programming have suggested that lisp is a major setback for the acceptance of functional programming, eg
http://www.cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf

3. One basic tenet of λ calculus
foo = λ x . exp
is equivalent to the more traditional
foo(x) = exp

is a little uh-uh in haskell thanks to the notorious monomorphism restriction
http://www.haskell.org/haskellwiki/Monomorphism_restriction

So if FP = λ calculus, Haskell does not quite make it!!