Ternery operator

[Andrew Chalk]

Is there a python equivalent of the C ternery operator?

I.e.:

fred = (x == 1) ? 12 : 15

If not, what's the best way to construct the same logic?

Regards

 

[Peter Hansen]

Is there a python equivalent of the C ternery operator?

See http://www.python.org/cgi-bin/faqw.py?query=4.16&req=search

 

[Andrew Chalk]

Wow! bang on topic. Thanks!

See http://www.python.org/cgi-bin/faqw.py?query=4.16&req=search

 

[Michael Geary]

See http://www.python.org/cgi-bin/faqw.py?query=4.16&req=search

As a newcomer to Python, I found it interesting to read the PEP for this:

http://www.python.org/peps/pep-0308.html

In retrospect, it seems obvious that the way the voting was conducted
insured that no ternary operator would be added to the language.

There were 16 proposed syntax options, and the requirement was that a
ternary operator would be added only if an clear majority picked a single
one of those options.

Well, with 16 options to choose from, it hardly seems surprising that none
achieved a majority-even though several of them drew quite a few votes, and
the most popular proposal did get more votes than the "reject all" option.

Four of the options got significantly more votes than the others. Those four
options combined got more than three times the number of votes that "reject
all" got.

It seems to me that the majority did want some kind of ternary operator, but
the large number of options prevented any one from being the clear winner. I
would wager that if the BDFL had picked his favorite from any of the most
popular options and said, "Now vote yes or no on *this* syntax", he would
have seen that clear majority he was looking for.

I suppose this is all water under the bridge now, since the PEP stated that
this was the community's one and only chance. I just can't help but think
that the voting system guaranteed the outcome--but it's Guido's language and
it was certainly his call to make.

-Mike (who just got my California voter's pamphlet with 135 candidates for
governor!)

 

[Fernando Perez]

In retrospect, it seems obvious that the way the voting was conducted
insured that no ternary operator would be added to the language.

Good point. I, for one, was one of the people who would have been very happy to
see some form of ternary go in. While I had my favorite, my biggest concern
was to have _some_ ternary, even if my favorite syntax didn't win (at least
amongst the most popular, which I felt were all fairly reasonable). Oh well,
this will remain one of my few pet peeves with the language for the long haul


Cheers,

f.

 

[Erik Max Francis]

I suppose this is all water under the bridge now, since the PEP stated
that
this was the community's one and only chance. I just can't help but
think
that the voting system guaranteed the outcome--but it's Guido's
language and
it was certainly his call to make.

I'm not sure any form of voting system would have changed the outcome.
The wording of the introduction to the PEP suggested that the BDFL did
not want the language feature, and put it to the community to prove to
him unequivocally that a very large majority of people wanted the
feature and wanted the same form of the feature, leaving him no choice
but to admit that the desire for it was too strong to ignore. I'm sure
he was well aware of the fact that that wasn't the case, but just wanted
to (in his mind) put the issue to bed.

As you say, it's his language, and it's most assuredly within his power
to do that. I personally wanted a conditional operator, and I'm
disappointed that the PEP was rejected, but I'm not surprised. (My only
specific complaint is that the decision came so many months after the
discussion and vote, and indirectly via a presentation at EuroPython,
but that's a separate issue.)

All I'll say beyond that is, if the goal of forcing a vote via a PEP
with the intent of closing the issue in the community, I think that's
wishful thinking. People will still ask for conditional operators,
people will still resort to unreadable, broken compromises like `C and x
or y' and there will still be discussion on it in the future. Mind you,
despite my favoring the PEP, I'm not suggesting that _that_ is a reason
to accept it; just that if one thinks that the issue won't come up over
and over again from the community in the future.

 

[John Roth]

As a newcomer to Python, I found it interesting to read the PEP for this:

http://www.python.org/peps/pep-0308.html

In retrospect, it seems obvious that the way the voting was conducted
insured that no ternary operator would be added to the language.

I absolutely concur. In fact, I thought that as soon as the voting style
was proposed.

There were 16 proposed syntax options, and the requirement was that a
ternary operator would be added only if an clear majority picked a single
one of those options.

I don't believe that was the case originally. I think the idea of
enumerating
suggestions and having a vote came later.

Well, with 16 options to choose from, it hardly seems surprising that none
achieved a majority-even though several of them drew quite a few votes, and
the most popular proposal did get more votes than the "reject all" option.
Yup.

Four of the options got significantly more votes than the others. Those four
options combined got more than three times the number of votes that "reject
all" got.

In other words, there was a super-majority to get something in.

It seems to me that the majority did want some kind of ternary operator, but
the large number of options prevented any one from being the clear winner. I
would wager that if the BDFL had picked his favorite from any of the most
popular options and said, "Now vote yes or no on *this* syntax", he would
have seen that clear majority he was looking for.

I agree. In fact, unless the syntax was truely awful, I'd have voted for it,
whatever it was. I don't regard myself as a language designer.

I suppose this is all water under the bridge now, since the PEP stated that
this was the community's one and only chance. I just can't help but think
that the voting system guaranteed the outcome--but it's Guido's language and
it was certainly his call to make.

I wouldn't cast the blame on Guido. It's quite clear that he doesn't
like the notion, but I don't get the impression that he's got the kind
of devious mind that would think this was the way to resolve it.
On the contrary, he seems to be a quite straightforward fellow in
most ways.

The whole notion of "one and only chance" is astonishingly naive.
There is no way that the vote on PEP 308 is going to keep people
from bring up the idea, and having the opponents refer to it as the
"community decision" when the vote was clearly in favor of having
the feature added to the language will simply drive people away
from the process.

-Mike (who just got my California voter's pamphlet with 135 candidates for
governor!)

Interesting thought there...

John Roth

 

[Uwe Schmitt]

Is there a python equivalent of the C ternery operator?

fred = (x == 1) ? 12 : 15

If not, what's the best way to construct the same logic?

fred = ( x==1 and [12] or [15])[0]

or

fred = [ 12, 15] [not x==1]

Further hints / explanations
at http://www.procoders.net/tutorials/boolean

Greetings, Uwe.

 

[Peter Hansen]

Is there a python equivalent of the C ternery operator?

fred = (x == 1) ? 12 : 15

If not, what's the best way to construct the same logic?

fred = ( x==1 and [12] or [15])[0]

or

fred = [ 12, 15] [not x==1]

I would think a *Python* equivalent to ?: should not use
direct equality comparison with 1. Better to drop the "==1"
parts in any of the above, to allow the usual Python interpretation
of what is True and what is False to occur.

....so fred = [12, 15][not x] is sufficient.

-Peter

 

[Gerrit Holl]

As a newcomer to Python, I found it interesting to read the PEP for this:

http://www.python.org/peps/pep-0308.html

In retrospect, it seems obvious that the way the voting was conducted
insured that no ternary operator would be added to the language.

It may be interesting to read the thread on c.l.py that took place befor
the vote was taken - it contains a lot of information, including a
discussion on this statement.

yours,
Gerrit.

 

[Paul Moore]

Actually, that's what Guido did do at first (IIRC). He proposed the
"expr1 if cond else expr2" form. The *community* argued against this
specific syntax, rather than concentrating on the semantics, and it
was only then that the discussion fragmented into endless discussions
over what syntax to choose.

The voting system was designed by the community and so we can't blame
anyone but ourselves for "rigging" the outcome...

THANK YOU. Your analysis of the process brings me a sense of relief. I
was also confused and frustrated by its failure to deliver what
(obviously) many of us wanted.

My feeling is that there is a majority who want a ternary operation
(not including me, but what the heck) but that there is violent
disagreement on the syntax.

I was dismayed by the process being defined as "the community's one
and only chance" and then set up to fail.

Well, I see it as Guido not really wanting to spend the time
implementing a ternary operator. He offered to, in any case, if the
community was in favour (and the PEP originally stated precisely what
he was offering). But with the proviso "if you don't like this, I'm
not going to offer again". I doubt he was surprised that the result
was a lot of discussion over syntax, rather than an acceptance of the
offer.

The general history of this issue is one of endless discussion with no
agreement. Maybe the majority would like the feature, but that same
majority can't agree on syntax. The PEP just forced one more iteration
of that process, and documented the result (lots of heated discussion,
but no solid conclusion).

Maybe it's a shame that Guido's original PEP wasn't preserved
unaltered. What's there now doesn't capture the flavour of the
original.

Of course, all of this is only my recollection, and just as prone to
being wrong as anyone else's...

Paul.

 

[Skip Montanaro]

Paul> Maybe it's a shame that Guido's original PEP wasn't preserved
Paul> unaltered. What's there now doesn't capture the flavour of the
Paul> original.

You can pick any version you like out of CVS, even if you don't have it
installed on your system. For the PEPs, start here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/peps/

Skip

 

[John Roth]

Actually, that's what Guido did do at first (IIRC). He proposed the
"expr1 if cond else expr2" form. The *community* argued against this
specific syntax, rather than concentrating on the semantics, and it
was only then that the discussion fragmented into endless discussions
over what syntax to choose.


The voting system was designed by the community and so we can't blame
anyone but ourselves for "rigging" the outcome...

I don't remember it that way. The way I remember it, it showed up one
day as a statement by someone that they were going to list all of the
suggestions so we could vote on it. There was some discussion of how
to vote, but before that I don't remember any discussion of structure.

It seems to me that the process was the typical "here's how I think it
should be done, and I'm willing to do all the work to make it happen,"
followed by a fair number of people not saying that they thought it was
a terminally stupid idea. You don't, after all, want to discourage
volunteers who actually want to work.

My feeling is that there is a majority who want a ternary operation
(not including me, but what the heck) but that there is violent
disagreement on the syntax.

There were also a lot of people who were fed up with the endless
debate, too.

The biggest difficulty, IMNSHO, was debating specific proposals
rather than debating constraints. If you debate constraints first, then
you can evaluate specific proposals against the constraints. That process
usually iterates to a conclusion rather swiftly.

However, I don't know how to make that shift in a public forum
such as c.l.py.

Well, I see it as Guido not really wanting to spend the time
implementing a ternary operator. He offered to, in any case, if the
community was in favour (and the PEP originally stated precisely what
he was offering). But with the proviso "if you don't like this, I'm
not going to offer again". I doubt he was surprised that the result
was a lot of discussion over syntax, rather than an acceptance of the
offer.

The general history of this issue is one of endless discussion with no
agreement. Maybe the majority would like the feature, but that same
majority can't agree on syntax. The PEP just forced one more iteration
of that process, and documented the result (lots of heated discussion,
but no solid conclusion).

Maybe it's a shame that Guido's original PEP wasn't preserved
unaltered. What's there now doesn't capture the flavour of the
original.

Agreed. There may be a copy floating around in someone's archives,
though. I'm not interested enough in assigning blame to go hunting,
we need a way to move forward that will get to a real agreement.

Of course, all of this is only my recollection, and just as prone to
being wrong as anyone else's...

Likewise.

John Roth

 

[Michael Geary]

I wouldn't cast the blame on Guido. It's quite clear that he doesn't
like the notion, but I don't get the impression that he's got the kind
of devious mind that would think this was the way to resolve it.
On the contrary, he seems to be a quite straightforward fellow in
most ways.

Very true, and I certainly didn't mean to imply that Guido or anyone else
deliberately set up the voting in a devious way.

The whole notion of "one and only chance" is astonishingly naive.
There is no way that the vote on PEP 308 is going to keep people
from bring up the idea, and having the opponents refer to it as the
"community decision" when the vote was clearly in favor of having
the feature added to the language will simply drive people away
from the process.

Yes, that was what troubled me when I read the PEP. My first reaction on
reading this statement in the introduction was that it seemed
disingenuous--but I'm sure it was not intentionally so:

"Following the discussion, a vote was held. While there was an overall
interest in having some form of if-then-else expressions, no one format was
able to draw majority support. Accordingly, the PEP was rejected due to the
lack of an overwhelming majority for change."

OTOH, in a different context I might be all for this approach:

Sacramento, October 8, 2003: "While the recall of Gray Davis passed by a
wide margin, none of the 135 replacement candidates was able to draw a
majority of the votes. Therefore, California will have no Governor."

I can only dream... ;-)

-Mike

(Gray Davis fans: I'm just kidding around with you, OK?)

 

[Uwe Schmitt]

I would think a *Python* equivalent to ?: should not use
direct equality comparison with 1. Better to drop the "==1"
parts in any of the above, to allow the usual Python interpretation
of what is True and what is False to occur.

...so fred = [12, 15][not x] is sufficient.

You made a mistake, compare :

[12,15][not x] (x==1) ? 12 : 15

x=0 15 15

x=1 12 12

x=2 12 15

Normaly you should simulate "C ? T : F"

either by
[T,F][not C]

or

(C and [T] or [F])[0]

in the first case T and F are evaluated allways,
the latter solution does short circuit evaluation,
which is according to the C/C++ semantics of the
ternary operator.

Greetings, Uwe.

 

[Peter Hansen]

I would think a *Python* equivalent to ?: should not use
direct equality comparison with 1. Better to drop the "==1"
parts in any of the above, to allow the usual Python interpretation
of what is True and what is False to occur.

...so fred = [12, 15][not x] is sufficient.

You made a mistake, compare :

True, sorry. I think I was thrown off by your explicit
comparison with 1 in the original, and my critical nature
homed in on that aspect, thinking you were presenting another
example of a non-Pythonic way of evaluating True/False.

I'll make this point instead: noting my mistake, and the
excited disagreement that followed in other replies (lots of
exclamation marks showing up!), this can only be seen as
yet more evidence that using any of those alternatives to
a simple if/else is rather too likely to be error prone for
anyone to prefer it.

-Peter