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

[Ian Kelly]

On Sat, Mar 22, 2014 at 9:16 PM, Rustom Mody <rustompmody at gmail.com> wrote:
> [I am not completely sure whether the following can be proved/is true]
>
> 1. One can change lambda's closure rules which would amount to
> "significant complexity for relatively little gain"
>
> 2. One can change comprehension rules to not reassign to the
> running comprehension running varible but to rebind, using a recursive
> function as the simulation of the comprehension rather than a for loop
>
> 3. 2 is semantically equivalent to 1

Well, if you accept that 1) amounts to significant complexity for
relatively little gain, and if 2) is semantically equivalent to 1),
then it follows that 2) also amounts to significant complexity for
relatively little gain.  My statement was in regard to the complexity
of the language, not the implementation of the language.

>    - trivially for normal (ie non-lambda containing) expressions
>    - and also for lambda containing expressions if your
>      default-argument trick is implemented by the python compiler
>      [This is the claim I am not completely sure of and would love to hear
>      of/if counter examples]

The disadvantage of the default argument trick is that it does modify
the function's signature, by adding an extra argument with a default,
so they're not entirely equivalent.

> Assuming its true:
>
> One *semantically specifies* a comprehension with a recursive function,
> not a for loop

The problem with this is a cognitive one.  The comprehension *looks
like* a for loop, not a recursive function.  It is natural to reason
about it as if it were a for loop, not a recursive function.  This is
that added complexity I was talking about.

> A vanilla python programmer need not know anything about this any
> more than a vanilla C programmer knows about
> - strength reduction
> - code hoisting
> - loop unrolling
> etc
>
> that goes on inside an optimizing C compiler

Until they go to unroll their comprehension into a for loop because
they need to add some imperative construct to it, and their code
breaks as a result.  From there you'll get the programmers who will
add functions with side effects to their comprehensions because they
want the comprehension binding behavior while still performing
imperative tasks within the loop.