For review: PEP 308 - If-then-else expression

[Andrew Dalke]

Dale Strickland-Clark:
> The important points are:
>
> 1. This is a proposal to extend expressions with a test to return one
> of two values (as apposed to an alternative to program flow logic).
>
> 2. It is desirable to evaluate only the result expression and not the
> discarded expression.

The important counterpoints have also been mentioned, and I don't
feel like summarizing them again.

> There is also an implicit requirement to by "Pythonic" -- something
> which I'm happy to ignore as it obviously means whatever the user of
> the term wants it to mean. It is a smokescreen for appearing
> pro-Python while really just being anti-change.

What's wrong with anti-change?  You say it like it's bad.  I like
that my code from 5 years ago still works and still (excepting a
few references to the string module) looks modern.

If you want to get that way, I could say that you are pro "change for
change's sake".

> I don't think anyone
> would describe list comprehension as Pythonic, yet this is perhaps the
> most useful recent addition to the language.

I admit that I was wrong about that one.  I was concerned that people
would start writing list comps like

  [x**y for x in range(10) for y in [z for z in range(x*2, x**2) if z % 9 >
2] if cos(x-y) > 0.25]

As it turns out, that hasn't been the case.  But I know that the ternary
operator
has lead to C/C++/Perl code which is very complicated.

I know because I did that.  I recall once helping someone in college on a
program, and I write a set if ?: statements.  He commented it

  # Andrew wrote this.  I don't know what it does, but it works.

> The other consideration often raised and used as an excuse for an
> objection or a standpoint are thoughts for the poor beginners.

And you'll see that those are written by people like Mark Lutz who
actually work with beginners on a near daily basis.  Or my own comments
about working with non-software developers who still program in Python.

> The widespread use of C++, Perl and TCL (to pick a few at random) is
> proof that beginners will persevere with anything that is of interest
> or benefit to them.

Years ago I introduced the scientists in the group to Tcl.  I used it as a
scripting language on top of my C++ code.  I was astonished that they
wrote hundreds of lines of Tcl to get things done.  So yes, beginners will
perservere.

Would they have done that in C++?  After all, the C++ code could do
exactly the same thing.  No, they would not.  They would have worked
on another program, or used the XPLOR or CHARMM scripting languages
(domain specific programming langauges).

I've also seen a Perl program written by a very good scientist.  It
had over 1,000 lines of Perl code and 0 functions.  It used gotos
for control flow.  So perserverence will yield results.

Doesn't mean there can't be better solutions.

> It is arbitrary and self-defeating to unnaturally
> constrict the enhancement of the language -- especially a feature you
> can take or leave -- because someone may not understand it. The people
> that like or want these syntactic frills will figure them out.

It is arbitrary and self-defeating to unnaturally enhance a language.

If this feature is useful (and I do not deny there are some places where
it would be very handy) then because of the nature of the feature it
is something that will be used everywhere.  So this is just the sort
of thing that a beginning programmer will need to learn to understand
how the code works.

That's doable when reading the code.  Now what about writing it?
When an if is needed, what are the rules to use one version over the
other?  I gave elsewhere a progression where the intial choice, to
use an if/else expression, leads naturally to code which is less clear
than code which always uses an if/else statement.

> As far as I can see, there are still only two serious contenders:

  ...if this proposal is accepted.

> Good. So we know they both work. The fact that they have been used
> elsewhere is surely a point in their favour.

And we know that the ternary has been used poorly, so it isn't a
full point in their favour.  The question is, how much less than a full
point is that?

> I don't see anyone objecting to
> using '*' as the multiply operator in spite of it being nothing like
> 'x' which most beginners seem to prefer.

The Python beginners I know usually have some experience in
FORTRAN or awk, or perhaps some BASIC, C, MatLab or Perl.
(Depends on the flavor of scientist I'm talking about.)  Hence they are used
to "*" for multiply or, when written in math terms, a dot or simple joining,
(Eg, as in Mathematica "a b" is used for "a*b")

> I think we can ignore those who simply flatly vote against this
> proposal. They obviously don't use the language as much as the rest of
> us or have a problem with change.

Do you also think we can ignore those who simply flatly vote for
this proposal, because they don't know how to write maintainable code
or because they want gratuitous change?

                    Andrew
                    dalke at dalkescientific.com