Defending the ternary operator

[Alexander Schmolck]

Andrew Koenig <ark at research.att.com> writes:

> Alexander> e.g. you always know that when you run into the token "if"
> Alexander> the context is as follows: ``if CONDITION: DO_SOMETHING
> Alexander> ...``.
> 
> This claim is already not true:
> 
>         y = [i for i in x if i != 0]

True. Still, that doesn't mean that allowing further grammatically distinct
"if"s wouldn't have a negative impact. The list comprehension "if" at least is
quite limited: there is no "else" part, you can't chain it and it occurs in a
fairly narrow context. Introducing an "if" expression would almost certainly
increase the impact:

if ...:
  y = [i if ... else ... for i if i ...] if  ... else ... 



> 
> Alexander> Introducing an "if" expression essentially means that both
> Alexander> forms will be used interchangably for a certain percentage
> Alexander> of cases, which I'd guess, makes *all* if expressions more
> Alexander> difficult to read (at least once interchangable use of both
> Alexander> forms has reached a certain frequency -- if that ever
> Alexander> happens (as I think it has in Ruby and Perl, BTW)).
> 
> I doubt it, because statements aren't interchangeable with expressions
> in general.  If they were, there would be no need for a conditional
> expression because we would already have one.

Also true; I was quite sloppy above. In Ruby there is no if "statement",
because like in lisp, there is no statement/expression dichotomy. Thus there
are actually 3 ways to do exactly the same "ternary":


irb(main):002:0> a = :foo if true
:foo
irb(main):003:0> a = if true then :foo end
:foo
irb(main):003:0> a = true ? :foo : nil
:foo

(proving that just because there is no need for something doesn't mean nobody
would add it ;)

As there is a (increasingly blurred) distinction between expressions and
statements in python, the amount of spurious variation wouldn't be quite that
large (I do find that variation unpleasant when reading ruby code, BTW). Still

   if a:
      b = c()
   else:
      b = d()
   
and
  
   b = c() if a else d()

are clearly interchangable in a slightly broader sense.


> 
> Try some examples and you'll see what I mean.
>

Oh, I'm pretty sure I know what you mean.

But I think that Python, for the better or the worse, has decided to seperate
relatively sharply between expressions and statements. There are some
advantages (e.g. more uniform code and less deeply nested expressions) and some
disadvantages (e.g. a loss of conciseness).

And I do certainly appreciate the style that results from everything being an
expression in lisp.

However, I can see little point in making python feel more like lisp. If I
want lisp, I program in lisp, not something that has evolved into a bad copy
thereof carrying around the remains of its former character as a mere
encumbrance and mark of its inferiority (<cough>C++</cough>:).

Let's just not have conditionals or assignments in expressions, even if we
already have lambdas and list comprehensions.


alex