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

[Chris Angelico]

On Mon, Apr 7, 2014 at 3:31 AM, Rustom Mody <rustompmody at gmail.com> wrote:
> However consider that some of the things that people did around 40 years
> ago and do today
>
> - use FORTRAN for numerical/simulation work --  now use scipy/sage etc
> - NLP with Lisp/Prolog -- look at Nltk
> - ??? with Data Analysis in Pandas
> - Scheme (basis for programming pedagogy, semantics research) -> Python
>
> you can add/multiply ad libitum
>
> Yeah you covered this in your (2) as "...just a tool..."
>
> Ask some recent PhD about what is for you "just" an almost irrelevant
> tool and you are very likely to find that that choice may well have
> been the difference between completing the research and giving up.
>
> I think python wins because it (usually) lets people do their thing

Allow me to put it another way. Mathematicians use the language of
algebra to describe their research; they don't, by and large, use a
programming language. They use pencils and paper [1] as tools to get
their work done, and may well have strong opinions on which pencil
brand is the best, but the point of the pencil (pun intended) is to
enable something else. It's supposed to get out of the way and let
them do their thing. Python is highly practical because it gets out of
the way. It's not the way that you develop programming language
theory, though.

I might start out designing a language with the express purpose of
implementing everything as an expression. The whole program consists
of one long expression, with perhaps the semicolon being a sequence
point that evaluates its left side, then evaluates its right side, and
returns the latter (like the C comma operator). I could then go
through a whole lot of lovely mental exploration as to what the
benefits and costs of that system are, all the while writing nothing
more than design documents and example code. At some point, if I'm
happy with it, I'll write a reference implementation, and maybe then
I'll use Python for the job. But that's not using Python to explore a
language concept; that's using Python to rapidly prototype the
executable code that I need in order to show my new language at work.
All the work of developing the language is done in the design stage,
with nothing at all even needing a computer (although I *guarantee*
you that if I were to start something like that, I'd find part way
through that I've made some fundamental mistakes early on - and a
computer is better for editing text than anything on paper). I could
just as easily write my reference implementation using yacc/bison and
C, and it wouldn't be materially different.

Using Python at the design stage would be what Steven's talking about
- actually using it to build the theory of programming. I have about
as much experience in the area as he has, so we can't speak to the
lack of examples, but that's the sort of example it would take.

ChrisA

[1] As the old joke goes: The physics department needs a whole lot of
expensive equipment, but the math department needs only pencils,
paper, and wastepaper baskets. And the philosophy department goes even
further: they don't need wastepaper baskets.