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

[holger krekel]

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?

good point :-)

> 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.

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

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

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

    <expression1> except <error>: <expression2>

which enhances Python's philosophy of not requiring 
Look-before-you-leap.  Hopefully it's obvious what
this does and IMO it reads comparatively well because
you don't have three entities (one condition and two expressions)
to parse.  With it you can substitute stuff like

    try:
        result = something.method()
    except AttributeError:
        result = None

with

    result = something.method() except AttributeError: None

which reads from left to right.  Maybe i just have been
working too much with exceptions, lately :-)

Just a side-thought,

    holger