For review: PEP 308 - If-then-else expression
pedronis at bluewin.ch
Sat Feb 8 23:15:24 CET 2003
From: "Paul Rubin" <phr-n2003b at NOSPAMnightsong.com>
> "Samuele Pedroni" <pedronis at bluewin.ch> writes:
> > I sympathize but the question is really what you prefer your target
> > encounter:
> > 1) sys.exit(errs and 1 or 0)
> > style = bold and "bold" or "italic"
> > or
> > 2) sys.exit(1 if errs else 0)
> > style = "bold" if bold else "italic"
> > because (1) idioms are used in practice.
> > Personally I have no problem with (1) idioms and I don't like (2) forms,
> > more in general I have yet to see a ternary cond op form that I like.
> > So I'm happy with the status quo, workarounds included and their
> > limititations.
> Your post is very interesting since it's the first one where I've
> heard someone actually claim to prefer (1) to (2), rather than offering
> (1) as a kludgy workaround but really preferring a multi-line if
my point is that if x can't be false, I could write (it's a mood thing):
return ... and x or ...
v = ... and x or ...
the std lib contains occurrences of the idiom. I can read them no problem.
" So I'm happy with the status quo, workarounds included and their
that implied that I'm fully aware of:
> FWIW I find the (1) forms awful and greatly prefer (2). Think of
> Andrew Koenig's example,
> maximum = x > y and x or y
> which follows the form of (1) but is simply incorrect some of the
> time, which you might not immediately notice. Who needs to expose
> themselves to that kind of error?
so avoid it.
maximum = max(x,y)
My position is odd, I can use properly and read the workarounds. I don't
like the proposed syntaxes and I don't feel to need badly enough of a
ternary cond op to declare to be ready to cope with the proposals.
I sympathize with those against for readability reasons, but I ask them to
think whether they really not prefer the proposals over the workarounds
because the latter are used.
I sympathize with Andrew Koenig because it would like ifs inside lambdas
but I prefer to frame that as the problem of lack of a notation for general
anonymous functions than as the problem of the missing conditional operator.
More information about the Python-list