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

[Ian Bicking]

On Fri, 2003-02-07 at 18:49, Andrew Dalke wrote:
> > PEP: 308
> > Title: If-then-else expression
> 
> -1 from me.
> 
> 1) Too many people like "cute" code, as in
> 
>    x = this if (x if y else z) else 1 if a > 0 else 2
> 
> (Put in parens until this is legal :)
> 
> 2) debugging these things is a bear
> 
> Suppose I want to say if a 2nd order polynomial of the
> form a*x**2 + b*z + c == 0 has real or imaginary roots.
> 
>   print "roots are", "real" if b** 2 - 4*a*c >= 0 else "imaginary"
> 
> (People will write this -- do you want this to be the future
> of Python?)

Yes!  That is very readable.  Besides the fact I haven't thought about
the quadriatic equation in years, this was very easy to read and
understand.  I use this pattern all the time:

if x:
    val = y
else:
    val = z

And I *hate* it.  "val = y if x else z" would often be better --
especially because z is None many times, or otherwise some trivial
value.  Often I don't need a temporary variable at all, and did not have
one until I started working out various corner cases.

I look at your current code:

>   descr  = b** 2 - 4*a*c
>   if descr >= 0:
>     root_type = "real"
>   else:
>    root_type = "imaginary"
>   print "roots are", root_type
 
And it does not look nice to me.  Why do you need the root_type
variable?  It's meaning can be easily inferred from the print statement
(much more easily than from the variable name), and it likely serves no
purpose after that portion of code.  But reading the code you don't
*know* it doesn't serve a purpose, you don't *know* that you can forget
about it.  You have to hold this variable mapping in your head while you
read the rest of the code in that scope.

Each time I look over the alternate code fragments it makes it more
clear that the inline if statement can create much more readable code. 
I think it is only fair to give Python programmers the option to make
their code more readable, and trust them not to also use it to make the
code less readable.  Not trusting the programmer is what C++ and Wirth's
languages do -- *that* isn't the Python way.

There are lots of Python features that can be abused.  People think
there aren't because Python programmers don't abuse them.  I don't think
we should overly exult Python's purity.

> But people will use ..if..else.. in very complex ways, because 1)
> it's easier to understand (when writing it) 

I don't think people will do this.  Reading nested inline if statements
-- just from the examples people have given -- is not easy.  I don't
think writing them would be easy either.  But I can imagine it happening
during maintenance, when a test may be put in with an inline if because
it means modifying the code less.  

> 2) people are used to this
> construct from C,  

Sometimes people do crazy things in C, but most C code doesn't overuse
?: either.

> and 3) because of 2) will have less exposure to
> a "that's a bad idea because it's harder for others to understand it"
> philosophy expressed in the rest of Python and use previous exposure
> to the "if it's got it we should use it" felt by many C coders.

I don't think people will make the connection -- it doesn't look very
much like the C ?:.  If anything it looks like Perl.  But maybe that's
not a good argument :)
 

-- 
Ian Bicking  ianb at colorstudy.com  http://colorstudy.com
4869 N. Talman Ave., Chicago, IL 60625  /  773-275-7241
"There is no flag large enough to cover the shame of 
 killing innocent people" -- Howard Zinn