PEP 308: "then" "else" for deprecating "and" "or" side effects

[Chermside, Michael]

Stephen Horne writes:
> I disagree with this. It sounds like the old 'sufficiency' argument -
> for example "you shouldn't have a subtract operator because addition
> and negation are sufficient".

And might I add, the persistent use of things like "cond and A or B" in
actual production Python code pretty much proves to me that the 
existing language features are NOT sufficient.

      [...]
> The fact that the arguments are lazy-evaluated is not, in my mind, a
> sufficient reason for claiming it isn't a function. Filter, map and
> reduce are also slightly unconventional (in that they take functions
> as parameters)

I find that statement rather puzzling. I personally write functions
all the time which take functions as parameters. It's not 
"unconventional" at all!

      [...]
> The idea of 'then' as an assertion that triggers backtracking on
> failure, and 'else' as an operator that can trap backtracking and
> provide an alternative is interesting, but probably just too obscure

I agree with you on this... 

      [...]
> If an
> operator-based form was to be used, I'd like a prefix to the syntax to
> tell me that a conditional expression is coming [...] leading to 
> something like...
> 
>     either x if c1 else y if c2 else z

Hmmm... I don't find the "either" useful myself, but I can understand
why you prefer it. I'll have to mull that one over. For what it's worth
(one vote's worth, I suppose), I find
       A if cond else B
highly readable, but somehow I'd prefer cond to come first, but
       if cond: A else: B
seems to have too much punctuation for an expression. I think
       cond then A else B
is probably unwise for the reasons you gave above. But I'm still
keeping an open mind on syntax.

-- Michael Chermside