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

[Rustom Mody]

On Sunday, April 6, 2014 11:24:15 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Apr 7, 2014 at 3:31 AM, Rustom Mody  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


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

HaHa! Very funny and unpleasantly accurate!


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

Right.
Whats wrong is (the implication -- maybe its not there??) that
CS begins and ends with "develop programming language theory"

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

Again I dispute the 'just'.

Its a right example for the wrong reason: State of art of writing
language implementations in python is no-better-probably-worse than
the venerable yacc ecosystem.
Choose an example where the difference between poor and good tool is more
palpable and the 'just' will no longer be upholdable as just.

Is the diff between cvs/svn and git "just one vcs or another"?

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

!Parse Error! What are you saying -- I don get :-)