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

[Andrew Dalke]

Me:
> To repeat, just because the language supports a ?:-like expression
> doesn't mean it's used.  I believe it is used many fewer times
> than it can be used.

James J. Besemer:
> This is just rhetoric.  It doesn't prove anything.
> 
> Nobody is saying ?: or equivalent is the best way to express your
> self in every single instance.

I want there to be "one-- and preferably only one --obvious way to do it."

It seems that the if/else expression does not lend itself to this
practice, and as proof I show that in existing languages which have
both if/else statements and if/else expression there isn't a strong
bias to use if/else expression.

> The arguments FOR conditional expressions generally involve side
> effects, or the readability/maintainability improvement of factoring
> out the common assignment from the individual terms.  Since there
> are no side effects in this and presumably many of your 'hits',
> then the two forms are genuinely equivalent and you would expect to
> see a mix.

I and others (including you, I believe) have analyzed existing C/C++
code to see how the if/else operator is used and misused in that
language and attempt to make predictions of usefulness in Python and
also gone and searched through existing Python code to see what
could use if/else expression vs. what *should* use if/else expression.

The conclusion I have derived from those analyses is that:
  - if/else will be used correctly in about 1 every 1,000 lines of
      Python code (the actual range is about 400 to 2,000 lines)

  - Of those, I give a ball-park estimate that about 1 in 4 are for
      non-trivial tests (eg, of the form '"spam" if x else "eggs"'
      where there are no computations) and about 1 in 10 are for
      true short-circuit tests where side effects affect the result.

     In other words, the side-effects argument comes into play
     about once every 3,600 to 20,000 lines of code, while the
     argument for a "iff(cond, true, false)" builtin function is
     rather stronger.

   - The readability argument is only about a +0.2 because I showed
     places where the if/else would be used in lieu of better
     techniques available in Python.  In my analysis (based on
     looking at code) I estimated about 1 misuse for every 2 proper
     uses.

     In addition, if if/else did not exist, the alternate approaches
     *could" be the and/or hack or some other harder to understand
     approach, but I believe most would use an if/else statement.

  - I also showed places where the easy of if/else would inspire
     people to write overly "cute" code which was not maintainable.

Se we are talking about a weak need which has a strong chance of
misuse.

> Too, your conclusion assumes that the code was all written by
> a single person.  In all likelihood, the code was written by
> different people, with different knowledge levels and individual
> prejudices.  It seems foolish to expect ?: to appear everywhere
> in a C program where it might fit, about as realistic to expect
> it would never appear.

The code I looked at was written about about 6 people.
Others looked at personal code, and I believe you looked at
the Python source.  The above results come from my meta-analysis
of those various works.

If you wish to assume otherwise, please feel free to do your
own analysis if when if/else *could* be used vs. *should* be
used vs will likely be *misused*.

> 1. maybe the person who wrote that particular piece of code
> didn't know about  ?:

In all cases, the code contained uses of ?:.  I am pretty
certain that all the authors of the code knew about that construct,
though I cannot verify that.

My believe is that ?: turns out to be rarely used, so it
isn't in most people's readily available set of idioms from
which to draw.  It's only inside of somewhat complicated
expressions (like 'print' statements or function calls) where
it pops to mind.  And I showed at least one case where starting
with that construct is likely to lead "naturally" to code which
is somewhat harder to understand then if an if/else statement
was used in the first place.

> 2. maybe the person knew ?: but didn't think to use it.

Bingo.  Which means that ?: is not a frequently used idiom,
even when available.  Which means that it's less important
than the proponents of this PEP advocate.

> 3. maybe the person in question, like you, knew all about ?:
> but was ideologically opposed to using it.

Ahh, but as I said, I want my code to feel appropriate to
the language used.  For C code, I have and will likely still
use the ?: inside of function call arguments to select from
one of two simple alternatives.  In C that is the expected
behaviour.

That does not mean that I want that to be expected Python
behaviour.

> 4. maybe the person for some reason thought the given expression
> was more clear in this case even though he knows about and uses :?
> outinely in other code.

Yes.  Which moderates the strength of the pro-PEP argument
by suggesting that it is not an overall win.

> 5. The code in question is the result of a bug, with the
> "return -1" accidentally having been omitted.  Simply adding
> the additional statement was the easiest mod for the maint.
> engineer to make and he didn't think to rewrite the surrounding
> code.

I do not know how the code developed so cannot address that.

> 6. I am sure there are other possibilities.

Indeed, but I believe it is enough to suggest that the overall
benefits of if/else are not all that great.

> More importantly, your [post] doesn't constitute an argument that
> the construct is bad.

When combined with an analysis of existing code, used as a projection
of how if/else might be used for Python code in the future, I
believe it does indeed constitute an argument that the construct
is bad.

Again, feel free to do your own analysis of source code and even
reanalyze the results I and others have posted on 1) the frequency
of ?: in C/C++ code, 2) the applicability of those cases to Python,
3) the likelihood of if/else use inappropriate used in Python, and
4) analysis of an existing Python code base to see when if/else
could be used both properly and improperly.

					Andrew
					dalke at dalkescientific.com