[Python-ideas] Python reviewed

[Stephen J. Turnbull]

Simon Lovell writes:

 > Hmm, Thanks Chris. I thought I was posting this to the correct
 > place.

Well, you didn't actually make any specific suggestions, and you
describe it as a "review" rather than an RFE.

 > I've never seen that "for line in open ..." after googling it many 
 > times! Why is this question so often asked then?

Lot of C programmers out there, I guess.  It's in all the textbooks
and references I have, and in the tutorial:
https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects

 > Re:PEP249 & SQL, I thought I was proposing something like that but it 
 > can't be tacked on later I don't think - needs to be an inate part of 
 > Python to work as cleanly as 4gl languages.

You should take a look at SQLAlchemy and other Python database
managers.  I don't know what your "untackable it" is so I can't be
more specific.

Note that PEP 249 is not intended to provide an API for ordinary
Python programmers' use.  It was expected that convenient management
modules would be provided on top of the DBAPI.  PEP 249 is intended to
provide an API between the backend drivers and the database manager
modules, so that any manager could easily interface with any driver.

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

There's only a point in arguing it if you think that data types are
fundamentally mutually exclusive.  But they're not in object-oriented
languages like Python.  Something can be object, boolean, and str all
at the same time.  (The presence of a type called boolean is a red
herring here.  True and False are merely the representative boolean
values, a convenience for programmers who want them.)

In Python, all data is boolean, unambiguously being interpreted as
"true" or "false" in boolean contexts.  As far as boolean contexts are
concerned, there are an infinite number of objects equivalent to True
and another bunch (currently not infinite) equivalent to False.

It could be argued that this leads to programmers making bugs, but I
personally haven't found it so, in Python or Lisp, and I find the lack
of it very annoying when I'm writing Scheme since it's so similar to
Lisp.

 > > 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.

 > > This could be done similarly to requiring declarations in
 > > Fortran, which if "implicit none" was added to the top of the
 > > program, declarations are required.

It could, but won't.  That's a pragma, and Guido hates pragmas.  It's
certainly not worth a keyword.

 > > "while((line=fgets(f))!=NULL)" which causes the confusion. No solutions
 > > have been accepted to the current method which is tacky:
 > >           f=open(file)
 > >           endwhile=""
 > >           endif=""
 > >           while True:
 > >               line=f.readline
 > >               if line = None:
 > >                   break
 > >               endif
 > >               process(line)
 > >           endwhile

Aside: I really find those suite terminators gratuitous; if I need
something "stronger" than a dedent, an empty line is much prettier
than they are IMO.

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

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

"for line in f" makes that unnecessary in this case, but there do
remain cases where loop-and-a-half is needed because of the lack of an
assignment expression.

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

Keywords are expensive in that every Python programmer needs to know
all of them to avoid using one as an identifier.  So it is a general
design principle of Python to avoid adding new ones where possible.
It turns out that for ... else is rarely used even by experts, and the
main use case is extremely idiomatic, so probably no harm is done.

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

It eliminates a keyword, makes it possible to experiment with
different implementations, and allows printing in the middle of
expressions (although since print() always returns None, that's not as
useful as it could be).

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

If you say so.  But it is convenient because list == list[:n] +
list[n:].

 > > Conditional expression (<true-value> if <condition> else
 > > <false-value>) in Python is less intuitive than in C (<condition>
 > > ?  <true-value> : <false-value>). Ref PEP308. Why BDFL chose the
 > > syntax he did is not at all clear.

I seem to recall that ?: was out because Guido at the time was
adamantly against use of ? as syntax in Python, so we were kinda stuck
with keywords.  He didn't want to have non-unary expressions start
with keywords (would have caused ugliness in the parser, I guess) and
he did want to reuse keywords. "<condition> then <true-value> else
<false-value>" was suggested but most who posted thought it less
readable than the syntax chosen.  YMMV, of course.

 > > The Ugly:
 > > Persisting with the crapulence from C where a non zero integer is
 > > true and zero is false - only ever done because C lacked a
 > > boolean data type.

There were at least four reasons for this in C, in fact, and none
have anything to do with the inability to add a Boolean type to a
programming language:

    (0) that's the way the hardware works
    (1) the idiom "if (ptr)"
    (2) the idiom "while (i--)"
    (3) the idiom "while (*dest++ = *src++)"

all of which compiled[1] nicely to efficient machine code without an
optimization pass, and some take advantage of useful characteristics
of the Unix OS.  Today one might argue that these are an attractive
nuisance and too cute to be allowed to live, but at that time not so
much was known about the kind of mistakes programmers like to make.


Footnotes: 
[1]  On modern machines (3) is handled more efficiently by specialized
instructions.