Defending the ternary operator

[David Eppstein]

In article <mailman.1044727707.17178.python-list at python.org>,
 Laura Creighton <lac at strakt.com> wrote:

> If you don't think that it will be used very often, do you admit that it
> might be on the side of 'diminishing returns', a feature request that
> doesn't 'pull enough weight' to be worth doing?  Or do you think that any
> language feature that is of use to somebody should automatically go into
> a language to 'add desired functionality'?  I doubt very much that you
> believe this, (though if you do, we have found the disagreement, for
> certain).  How do you determine if a proposed language feature 'pulls
> enough weight'? 

My impression is that a ternary operator is already used, often, in the 
guise of "x and y or z" or "[z,y][x]" or still worse 
"[lambda:y,lambda:z][not x]()". Introducing a true ternary operator 
might at least prevent programmers from committing such atrocities.

But, programmers uninterested in writing readable code will anyway find 
other ways to be unreadable.  What I am not sure about is whether the 
gain in readability of code compared to the existing ternary hacks is 
enough to outweigh the increase in cognitive complexity of one more 
language feature.  I am pretty sure that GvR is better at judging that 
kind of balance than I am, though, so I don't see a lot of point in 
subjecting the matter to a vote.

-- 
David Eppstein       UC Irvine Dept. of Information & Computer Science
eppstein at ics.uci.edu http://www.ics.uci.edu/~eppstein/