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

[Christian Tismer]

Dave Brueck wrote:
> On Sat, 8 Feb 2003, Christian Tismer 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.
One of Pythons's strengths was to make it easy to write
readably programs and difficult not to.
It is loosing this strength a little bit.
Conditional expressions are the next consequent step
into that direction.

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

The problem does not exist, it is being raised
over and over again by people who have enough time
to ask for new constructs which add more to learn,
but rather small or no new functionality.

> Yes, at the lowest
> levels this is a control flow operator (test+jump). But in the
> higher-level Python sense this _isn't_ a control flow operator but a
> _choice_ operator - and it's much closer to logical operators like "and"
> and "or".

How does this make a difference?
Is thinking of choice any better?
Real choice would be extensible to many choices,
and this is clearly not achieved and impossible
with the proposed syntax.
Not enough, it also imposes the need to remember
new priorities.

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

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

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

I still prefer to read from left to right,
from top to bottom and to do as few lookaheads
as possible.

- chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/