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

[Andrew Koenig]

holger> Andrew Koenig wrote:
Laura> Thus answering the question 'if we let it in will we get code that
Laura> is hard to read'.  I want my control flow with indentation, please.

holger> very good point. 

>> Yes, but in what direction does it argue?

holger> good point :-)

Thank you!

>> In C, I don't consider ?: to be control flow, any more than
>> I consider && or || to be control flow.  In fact, part of
>> reason that conditional expressions appeal to me is that they
>> permit some kinds of expressions to be written *without* control
>> flow that otherwise would require it.

holger> IMO Laura emphasized how good enforcing indentation is for
holger> readability.  Writing 'x and y or z' or 'x if y else z'
holger> (or list-comps for that matteR) undermines readability.  

I think that sometimes it does, and other times it doesn't.
To borrow an example from another thread, I consider

	  print n, "error" if n == 1 else "errors"

to be more readable than

	  if n == 1:
	      print n, "error"
	  else:
	      print n, "errors"

partly because there is only one flow of control so it is easy to see
that n is printed in all cases.

holger> Beeing able to concisely express a "binary choice"
holger> in an expression of course can be nice in some cases. 
holger> It's a tradeoff between readability and 'expression power' but i think 
holger> that readability should score higher here. Often enough,
holger> there are other (higher-level) possibilities to design an 
holger> algorithm using dictionary-dispatching.  

holger> I think what *could* be more useful is something like 

holger>     <expression1> except <error>: <expression2>

holger> which enhances Python's philosophy of not requiring 
holger> Look-before-you-leap.

I agree.  In fact, in ML that's the only way of handling exceptions
(and <expression1> and <expression2> must have the same type).