[Python-ideas] Python reviewed

[Chris Barker]

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 at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170109/c0352beb/attachment-0001.html>