Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3a.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <53418644$0$29993$c3e8da3$5496439d@news.astraweb.com>
References: <9daf0806-02de-4447-964c-c8f8953c23e5@googlegroups.com> <mailman.8478.1395710470.18130.python-list@python.org> <lgqq99$v5j$1@speranza.aioe.org> <lgtsga$2ei$1@dont-email.me> <lh1h1f$ov3$1@speranza.aioe.org> <5334c38e$0$29994$c3e8da3$5496439d@news.astraweb.com> <lh4ouu$n8l$1@speranza.aioe.org> <53364327$0$29994$c3e8da3$5496439d@news.astraweb.com> <lh5iqs$j0m$1@speranza.aioe.org> <mailman.8683.1396069736.18130.python-list@python.org> <53365F55.2040302@gmail.com> <mailman.8688.1396073027.18130.python-list@python.org> <lh5vq3$c1j$1@speranza.aioe.org> <533836c4$0$29994$c3e8da3$5496439d@news.astraweb.com> <lhb0on$pcj$1@speranza.aioe.org> <op.xdltbjr05079vu@gnudebeest> <lhfatq$hrj$1@speranza.aioe.org> <mailman.8830.1396532123.18130.python-list@python.org> <lhk2pi$nnf$1@speranza.aioe.org> <533e811a$0$29993$c3e8da3$5496439d@news.astraweb.com> <lhqmvk$paq$1@speranza.aioe.org> <874n26su9f.fsf@elektro.pacujo.net> <53418644$0$29993$c3e8da3$5496439d@news.astraweb.com>
Date: Mon, 7 Apr 2014 03:27:56 +1000
Subject: Re: Explanation of this Python language feature? [x for x in x for x in x] (to flatten a nested list)
From: Chris Angelico <rosuav@gmail.com>
Cc: "python-list@python.org" <python-list@python.org>
Content-Type: text/plain; charset=UTF-8
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8955.1396805656.18130.python-list@python.org>
Lines: 59
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:69772

On Mon, Apr 7, 2014 at 2:52 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> (4) This is the category which I was referring to when I said that Python
> wasn't a "computer-science-ey language": do people use Python for
> research into language-independent fundamental principles of computation?
> I don't think so. I agree with Marko that normally you:
>
>> you either use a pseudolanguage or some sort of formalism that
>> hasn't been implemented.
>
> E.g. most of the really deep stuff by Turing wasn't even performed on a
> computer...

A simple reason for that is summed up in the Zen of Python:
Practicality beats purity. For a comp sci theoretical study, you want
something that exemplifies purity. That's why you get examples like
the ones mentioned below - a dining philosopher is fundamentally
unable to do such a simple thing as look to see what his neighbours
are doing, and is also apparently unable to think and eat at the same
time (plus, why on earth can't they afford a few more forks in the
interests of hygiene??!?). Defining all of mathematics in terms of
lambda is wonderfully pure, and utterly useless for any practical
purpose.

It's the same, in my opinion, with the eternal arguments about
functional vs imperative vs declarative programming languages, and
with the differences between compilers and interpreters, and whether
something's a second-generation or third-generation or
fourth-generation language. You can define all those terms in nice
pure ways ("a compiler translates code into something that can be
executed directly, but an interpreter parses code bit by bit and
executes it"), but most actually-usable systems blur the lines. I
still haven't seen any real definition of FP or OOP (especially the
latter, O!) that doesn't ultimately come down to "avoid these language
features which violate FP/OOP principles", which means that most
programming languages (and more so with popular languages) are neither
and/or both. It's all very well to say that everything is a function
whose return value depends solely on its arguments, but practicality
demands that you allow side effects in certain places. And it's all
very well to say that everything's an object and every bit of code is
a method, but aiming too far for purity results in Java-like syntactic
salt. Pike avoids this somewhat by letting you pretend that it's a
C-like module with top-level functions, but actually it's instantiated
an object and called a method on it. That's occasionally useful, but
most of the time you just ignore it and work imperatively. Python goes
a bit further: top-level is just code like anything else, and it gets
executed straight down the line. Practicality beats purity.

>>  * unfaithful husbands on an island ruled by female logicians
>
> I don't know that one.

Me neither, although I can see elements of classic logic analysis
elements. Islands ruled by logicians, people who always tell the truth
/ always tell exact falsehoods, etc, etc. I don't know of any that
involve unfaithful husbands, but it wouldn't surprise me. Would like
to hear it though.

ChrisA