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

[Dave Brueck]

On Sun, 9 Feb 2003, Christian Tismer wrote:

> Dave Brueck wrote:
> >>listcomps are leading to "uncomprehensions". I would
> >>like to see them dropped as a step in the wrong direction.
> >
> > Not me - when used properly they really add to the readability of my code.
> > I'm glad we have 'em!
>
> "When used properly" applies to almost every construct.

Obviously - I don't think anyone argues that. But it's simply your opinion
that it lowers readability. IMO it raises it, that's all. Yay, we all have
opinions.

> >>The proposed syntax is counterintuitive for me by two reasons:
> >>
> >>a) control flow in Python always involves special characters.
> >>    It should at least have some markup at the start and end.
> >
> > That's part of the problem: you're thinking of control flow in the
> > assembly-language sense and not in the Python sense.
>
> How is my thinking part of the problem, please?

Because your original comment implied that if-expressions are for control
flow. They are, but only at the lowest (bytecode or assembly language)
level. In terms of program logic (what the developer is thinking about),
if-expressions _aren't_ for control flow, in the normal sense of the term.

> > It has no special characters because (1) the keywords used have
> > the saming meaning as always and (2) it's an expression, not a statement.
>
> Aha. So you propose to replace + - * / ** by keywords.

What in the world are you talking about? The PEP uses 'if' and 'else' -
keywords that already have well-understood meaning in Python, and their
meaning is the same in all contexts. I have no idea how you get from that
the idea that I want to replace other operators with keywords.

> >>b) reading and execution order should match as much as possible.
> >
> > Why? Do reading and execution order match here?
> >
> > x.append((x+y, w+z))
>  >
> > Nope! If they did, we would write it something like:
> >
> > x+y, w+x toTuple applyTo x.append
>
> Makes no sense to me. It is clear that pure left to
> right evaluation would forbid any infix operators.
> In the append case, everything is fine: You append a
> single tuple, which happens to be created inplace.
> This was one of the reasons to replace the string
> module by methods, which turned bulks of execution
> ordering braces into rather linear sequences of
> method calls. Improvements are always posible.

Ok - reread the last few paragraphs. You said that reading and execution
order should match as much as possible, I'm simply pointing out that in
practice that happens far less often than you think, and it doesn't seem
to cause people any problems. Most likely people read whole statements at
a time anyway, so in practice I doubt there's much LtoR, RtoL reading
going on anyway, and if there is it's in whole groups of tokens rather
than individual ones.

> > But would you like to read
>          true-statement
>       if condition:
>       else:
>          false-statement
> or something like that?

Of course not, that's silly and overly verbose.

The order of logic in the PEP isn't troubling: "use that door if it's
open, otherwise use the back door" makes perfect sense. My perception is
that some people react negatively to the proposed ordering more out of
unfamiliarity than anything else - it doesn't take much effort to get
accustomed to it.

-Dave