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

Ian Kelly ian.g.kelly at gmail.com
Mon Mar 24 10:03:12 CET 2014

On Mar 23, 2014 11:56 PM, "Mark H Harris" <harrismh777 at gmail.com> wrote:
> 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

That post doesn't point out anything "wrong" with lambda. The argument
boils down to: 1) map and filter are not useful because we have
comprehensions; 2) reduce is confusing; 3) if we remove those then lambda
is not useful either.

> 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.

The difference does not really lie in the lambda construct per se but in
the binding style of closures. Functional languages tend to go one way
here; imperative languages tend to go the other. Python being primarily an
imperative language follows the imperative model. Anonymous functions in
Python work the same way in this regard as anonymous functions in Lua or
ECMAScript or Go -- those other languages merely avoid the cardinal sin of
defining their anonymous functions using the keyword "lambda". The result
may be more surprising to users accustomed to functional languages, but I
claim that it is *less* surprising to users of other imperative languages.

>> 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.

Oh, give me a break. If you find that you can't write functional code in
Python just because closure bindings are slightly inconvenient, then you
can't be trying very hard.

>    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.

And I would hope that anybody who uses Python is likewise aware from the
stay that it *isn't* a purely functional language.

>> Python could deprecate many things. It would make Python a worse
>    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.

If lambda were going to be deprecated and removed then it already would
have happened in Python 3, because Guido tried to do precisely that. I'm
not sure what the reasons were for keeping it in the end (according to PEP
3099 it was because nobody suggested a suitable replacement), but if he
couldn't get rid of it then, he never will.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20140324/602cb563/attachment.html>

More information about the Python-list mailing list