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.bar...@noaa.gov
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
