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

[Mark H Harris]

On 3/22/14 4:46 AM, Steven D'Aprano wrote:
> On Fri, 21 Mar 2014 23:51:38 -0500, Mark H Harris wrote:
>
>> Lambda is a problem, if only because it causes confusion. What's the
>> problem?  Glad you asked. The constructs DO NOT work the way most people
>> would expect them to, having limited knowledge of python!

    One of the best links for understanding what is wrong with lambda is 
here, from Guido, (by the way I agree totally with his assessment, there 
is no point really in writing it out again):

   http://www.artima.com/weblogs/viewpost.jsp?thread=98196


> Why is that a problem? Would you consider it a problem that people who
> don't understand BASIC can't understand BASIC? ("I don't get the
> difference between GOTO and GOSUB. {snip}
>
> The problem is ignorance, not the calculator, and not lambda.

    You're argument, based on analogy, is also a red herring, as well a 
straw man. Lambda is a problem of confusion for scientists and other 
mathematicians (amateur and otherwise) who may be confused because 
python's lambda does not do precisely what they might expect from other 
functional programming languages, nor does it match precisely with the 
lambda calculus. Its also confusing to sophisticated users of all 
stripes who may not be aware of "lambda" at all.

> You've told us that "most people" (which people? dentists? lawyers?
> illiterate tribesmen from the Amazon? professional programmers?) are
> surprised by lamba's behaviour, but you haven't actually told us what
> behaviour is surprising, or what "most people" expect lambda to do.
> Perhaps you ought to?

    I love your rhetoric, actually, but red herrings all . . .

    Here is a link that advocates lambda (map, filter, and reduce) as a 
very powerful construct for doing various things:  I agree:

http://www.secnetix.de/olli/Python/lambda_functions.hawk

    Its a great link, but the important sentence for this discussion is 
this unique quote, about "lambda,"

 >"This is not exactly the same as lambda in functional
> programming languages, but it is a very powerful concept . . ."

    People who understand lambda from functional languages must hassle 
with the fact that lambda is different in python, and people who do not 
understand functional programming languages (nor the lambda calculus) 
are confused by the syntax, also just what it does.


> Python is not a pure functional language, but you can write functional
> code in it. If you want a pure functional language, you know where to
> find one.

    Yes, that's obvious; but you're missing the point. Python is not a 
functional language, and implying that it can be used as one is 
misleading at best (maybe a lie at worst) just because it has a 
construct for generating a dynamic anonymous function.

> (I wonder whether, say, Haskell has the people coming along and demanding
> that it should become more like Python?)

    Another straw man.

    Well, number one, I'm not demanding anything. Number two, everyone 
who uses Haskell (for whatever reason) knows well from the start that 
its a pure functional programming language. That is the advertisement, 
and that is the expectation. No one expects anything different.

>> I can see uses for python's lambda.  But, honestly, I think python could
>> deprecate its use and in five years just remove it from the language;
>> along with filter, map, and reduce !
>
> Python could deprecate many things. It would make Python a worse language.

    How so?  Read Guido's argument above. Another way to answer this 
question is that I have been programming with Python for almost a decade 
and I've not used lambda. In fact, I have gone out of my way to NOT use 
lambda because I am fully aware that the BDFL hates it. Reduce is no 
longer in the standard library (although you can import it) and there 
are equally good ways to do what lambda was designed for without the 
hassle nor confusion.

> By the way, are you aware that lambda is *identical* to def except for
> three things?
>
> - lambda is an expression, not a statement like def;
>
> - the body of a function created with lambda is limited to a
>    single expression, not a block;
>
> - the function object created with lambda has a generic name.

    Absolutely, thank you for pointing those out !  You forgot that 
lambdas can be used in expressions while def functions may not... but 
you really have proved my point.  There is so little difference between 
the two that (for the sake of clarity and reducing confusion) it might 
be good to just remove the lambda thing altogether.  Just say'in.

> So unless the surprising behaviour about lambda that you're about to tell
> us about relates to one of those three things, I *guarantee* that
> functions created with def have the same surprising behaviour.

    No, the surprising behavior is that python lambda does not work 
exactly the way that lambda works in functional programming languages 
(see the two links provided) the confusion it creates for "normal" users 
does not warrant its inclusion in the language.

    Having said that, I must admit that I've "played" with lambda 
extensively and find it interesting from a comp sci standpoint, but, 
again, for normal users I don't think there is a really good value add 
for having it in the language.