reading file to list
rhodri at wildebst.demon.co.uk
Wed Jan 21 02:34:37 CET 2009
On Tue, 20 Jan 2009 03:39:45 -0000, Xah Lee <xahlee at gmail.com> wrote:
> On Jan 19, 4:49 pm, "Rhodri James" <rho... at wildebst.demon.co.uk>
>> On Sun, 18 Jan 2009 08:31:15 -0000, Xah Lee <xah... at gmail.com> wrote:
>> > On Jan 17, 10:25 am, Tino Wildenhain <t... at wildenhain.de> wrote:
>> >> > [[int(x) for x in line.split()] for line in open("blob.txt")]
>> > Nice (python code).
>> > Few comments:
>> > • the above code is borderline of atypical. e.g. it is not a average
>> > python code would produce or one'd seen in corporate python code.
>> I can't imagine why not.
> consider code produced by corporations, as opposed to with respect to
> some academic or philsophical logical analysis. Looked in another way,
> consider if we can compile stat of all existing pyhton code used in
> real world, you'll find the above style is rarely used.
I *was* thinking of code produced in the real world, and I don't buy
your assertion. I'm not an academic, and I wouldn't hesitate to lay
down a line of code like that. As I said before, it fits into English
language idioms naturally, and as a result is pretty self-descriptive.
> in a logical analysis, each lang fanatics will actively sell certain
> style of construction, but that's just not the way code in the real
> world are. Ample examples can be found especially in other cultish
> lang groups such as lisp, perl, etc. (less of this phenomenon is found
> create fancy constructions in the name of improvement or esthetics or
> weird philosophy in the first place.)
Long experience particularly in C suggests that you are entirely wrong.
You are conflating simplicity with flexibility; C is a simple language,
but it is very syntactically flexible, and programmers not only can but
do regularly and with malice aforethought write horribly convoluted
code. Sometimes this is out of cunning (dropping through cases in a
switch statement, for instance), sometimes because the language is too
simple (function dispatch tables can look gruesome if you aren't
careful), and sometimes it's because you need a particular sequence of
instructions to get the optimiser to Do The Right Thing; regardless,
it happens in a large fraction of non-trivial C programs.
>> > The above line illustrate well the ad hoc syntax soup nature python is
>> > moving into.
>> To a native English speaker, it illustrates entirely the reverse.
>> List comprehension is actually quite a linguistically natural way
>> to express the iterative construction of a list.
> computer lang is not human lang. In argument based on human lang, you
> have AppleScript, Perl, which are un-readable or cumbersome to most
> programers. Even with human lang, if you know linguistics to some
> extend, you know that natural lang is a complete wortheless mess in
> every aspect with respect to “design” qualities.
Having studied natural languages, I am well aware that the designers
of AppleScript didn't study natural languages. If they had, they'd
have been a lot more careful in their choice of constructs to map
AppleScript onto English less ambiguously.
I can't think of a language less like AppleScript than Perl, which
is incomprehesible for entirely different reasons. Grouping them
together as if they had anything else in common is... eccentric.
Computer languages are not human languages, but computer language
constructs do attempt to map onto human language constructs to
provide some measure of comprehensibility. Where a construct like
list comprehension maps very well onto idiomatic English, dismissing
it as "ad hoc syntax soup" is just plain wrong.
Rhodri James *-* Wildebeeste Herder to the Masses
More information about the Python-list