not even sure why Im engaging, but....

Note 1) Many of these issues have been widely discussed all over the internet -- I don't think I've seen anything new here. So it would have been nice to do some more research before posting.

Now into the fray!

> Re:Everything being true of false. I don't see the value of
> that. Only boolean data should be valid in boolean contexts.

I actually agree with that -- but there are a lot of nice conveniences from Python's idea of "truthiness", too.

> > The Bad:
> > Colons at the end of if/while/for blocks. Most of the arguments
> > in favour of this decision boil down to PEP 20.2 "Explicit is
> > better than implicit".

I seem to recall that this has to do with an implementation
requirement, that the syntax be parseable with an LL parser.

I don't so -- but I DO think that this was a usability issue that was investigated early in PYthon's development. (Or maybe even ABC's development) -- in fact, I suspect is is one of the few programming language syntax decisions (in any language) that went through any kind of formal usability testing.

I didn't bring it up -- so I'll leave the googling to others.

> Actually the accepted loop-and-a-half idiom is

f = open(file)
line = f.readline()
while line:
process(line)
line = f.readline()

I used to write that style, but I've never liked it, so went with:

f = open(file)

while True:

line = f.readline()

if not f:

break

process(line)

the while True and check for a break is kinda ugly, but I think less ugly than two separate calls to readline()

and, of course, we now have:

for line in f:

process(line)

which is cleaner an easier than anything I've seen in any other language

-- so WHAT exactly was the original complaint???

> > else keyword at the end of while loops is not obvious to those
> > not familiar with it. Something more like whenFalse would be
> > clearer

I've kinda wanted an "do-until" loop of some sort sometimes, but frankly, not that badly :-)

> > Changing print from a statement to a function in Python 3 adds no
> > positive value that I can see

yeah, yeah yeah -- PLEASE go read an number of py3 justifications and rants! This is really a dead horse.

> > Upper delimiters being exclusive while lower delimiters are
> > inclusive. This is very counter intuitive.

but SO much better than the alternative!

This was also tested som, I think maybe by Dijkstra of C++ fame.

but these identities are REALLY, REALLY useful:

s[:n] + s[n:] == s

len(s[:n]) == n

len(s[:-n]) == n

len(s[n:i]) == i - n

(maybe a few others?)

These prevent a HUGE number of off by one errors and ecta code adding and subtracting one all over the place -- this is almost as important to Pythons' usability as the significant indentation :-)

> > Conditional expression (<true-value> if <condition> else
> > <false-value>) in Python is less intuitive than in C (<condition>
> > ? <true-value> : <false-value>).

Ha Ha Ha Ha!!! I could read and understand Python's version the first time I saw it -- I still have to look up the C version (not much of C programmer). maybe you think it's wordy -- but it's very readable.

-CHB

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA 98115   (206) 526-6317   main reception

Chris.Barker@noaa.gov