Proposed PEP for a Conditional Expression

[Terry Reedy]

<thp at cs.ucr.edu> wrote in message news:9nnh8u$5qf$4 at glue.ucr.edu...
> Terry Reedy <tjreedy at home.com> wrote:
>
> : <thp at cs.ucr.edu> wrote in message
news:9nkvss$cmq$1 at glue.ucr.edu...
> :> :           WORKAROUND_2: (this SOMETIMES works)
> :> :              > x = c and a or b
>
> :> The problem of determining whether or not a given expression ever
> :> evaluates to false is equivalent to determining whether a given
> : Turing
> :> machine halts, i.e., the general case is not algorithmically
> : solvable.
>
> : True, but so what?  Most real examples seem to involve constants
that
> : are triviallly either true or false or simple expressions that are
> : trivial to decide in context.
>
> I agree that "most" real examples fall into this category, but we
> still need a general selection operator for the rest.

For which there *is* the sequence[0] hack, which I readily admit is
very much of a hack.

> Also, using the short-circuited evaluation of logical operators for
> selection is something of a hack.  Sure it's an idiom that people
can get used to,

Let me admit it here.  I *like* the and/or hack/idiom because I
thought of it all by myself when I had occasion to need the equivalent
of C's :/; (which I also used freely).

> but I would prefer code to say what it means more  directly.

I would not mind a direct conditional expression being added.  I do
mind any pretense that there is no alternative.  Since I like the form
of C's conditional, most of the alternatives proposed strike me as
hackier and less gracious than and/or.  If it does not conflict with
the existing grammar, I would go for

<condition> if <expression a> else <expression>

as being a Pythonic translation of ? : constructions since I read ? as
'if' and : as 'else'.

Terry J. Reedy