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

[Samuele Pedroni]

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
group to
> > 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,
or
> > 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
statement.

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.

I wrote:
" So I'm happy with the status quo, workarounds included and their
 limititations."

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.

regards.