<div dir="ltr">not even sure why Im engaging, but....<div><br></div><div>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.</div><div><br></div><div>Now into the fray!</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"> > Re:Everything being true of false. I don't see the value of<br>
> that. Only boolean data should be valid in boolean contexts.</span></blockquote><div><br></div><div>I actually agree with that -- but there are a lot of nice conveniences from Python's idea of "truthiness", too.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"> > > The Bad:<br>
> > Colons at the end of if/while/for blocks. Most of the arguments<br>
> > in favour of this decision boil down to PEP 20.2 "Explicit is<br>
> > better than implicit".<br>
<br>
</span>I seem to recall that this has to do with an implementation<br>
requirement, that the syntax be parseable with an LL parser.</blockquote><div><br></div><div>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.</div><div><br></div><div>I didn't bring it up -- so I'll leave the googling to others.</div><div><br></div><div> > Actually the accepted loop-and-a-half idiom is</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
f = open(file)<br>
line = f.readline()<br>
while line:<br>
process(line)<br>
line = f.readline()<br></blockquote><div><br></div><div>I used to write that style, but I've never liked it, so went with:</div><div><br></div><div><font face="monospace, monospace">f = open(file)</font></div><div><font face="monospace, monospace">while True:</font></div><div><font face="monospace, monospace"> line = f.readline()</font></div><div><font face="monospace, monospace"> if not f:</font></div><div><font face="monospace, monospace"> break</font></div><div><font face="monospace, monospace"> process(line)</font></div><div><br></div><div>the while True and check for a break is kinda ugly, but I think less ugly than two separate calls to readline()</div><div><br></div><div>and, of course, we now have:</div><div><br></div><div>for line in f:</div><div> process(line)</div><div><br></div><div>which is cleaner an easier than anything I've seen in any other language </div><div><br></div><div>-- so WHAT exactly was the original complaint???</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"> > > else keyword at the end of while loops is not obvious to those<br>
> > not familiar with it. Something more like whenFalse would be<br>
> > clearer<br></span></blockquote><div><br></div><div>I've kinda wanted an "do-until" loop of some sort sometimes, but frankly, not that badly :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> > Changing print from a statement to a function in Python 3 adds no<br>
> > positive value that I can see<br></span></blockquote><div><br></div><div>yeah, yeah yeah -- PLEASE go read an number of py3 justifications and rants! This is really a dead horse.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"> > > Upper delimiters being exclusive while lower delimiters are<br>
> > inclusive. This is very counter intuitive.<br></span></blockquote><div><br></div><div>but SO much better than the alternative!</div><div><br></div><div>This was also tested som, I think maybe by Dijkstra of C++ fame.</div><div><br></div><div>but these identities are REALLY, REALLY useful:</div><div><br></div><div><font face="monospace, monospace">s[:n] + s[n:] == s</font></div><div><font face="monospace, monospace">len(s[:n]) == n</font></div><div><font face="monospace, monospace">len(s[:-n]) == n</font></div><div><font face="monospace, monospace">len(s[n:i]) == i - n</font></div><div><font face="monospace, monospace"><br></font></div>(maybe a few others?)</div><div class="gmail_quote">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 :-) <div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> > Conditional expression (<true-value> if <condition> else<br>
> > <false-value>) in Python is less intuitive than in C (<condition><br>
> > ? <true-value> : <false-value>). </span></blockquote><div><br></div><div>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.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R (206) 526-6959 voice<br>7600 Sand Point Way NE (206) 526-6329 fax<br>Seattle, WA 98115 (206) 526-6317 main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div></div>