PEP 308: "then" "else" for deprecating "and" "or" side effects
Chermside, Michael
mchermside at ingdirect.com
Fri Feb 14 14:32:44 EST 2003
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
More information about the Python-list
mailing list