Ternery operator

Discussion in 'Python' started by Andrew Chalk, Sep 7, 2003.

  1. Andrew Chalk

    Andrew Chalk Guest

    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
    Andrew Chalk, Sep 7, 2003
    #1
    1. Advertising

  2. Andrew Chalk

    Peter Hansen Guest

    Peter Hansen, Sep 7, 2003
    #2
    1. Advertising

  3. Andrew Chalk

    Andrew Chalk Guest

    Andrew Chalk, Sep 8, 2003
    #3
  4. Ternary operator (Re: Ternery operator)

    > Andrew Chalk wrote:
    > > Is there a python equivalent of the C ternery operator?


    Peter Hansen wrote:
    > 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!)
    Michael Geary, Sep 8, 2003
    #4
  5. Re: Ternary operator (Re: Ternery operator)

    Michael Geary wrote:

    > 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.
    Fernando Perez, Sep 8, 2003
    #5
  6. Re: Ternary operator (Re: Ternery operator)

    Michael Geary wrote:

    > 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.

    --
    Erik Max Francis && && http://www.alcyone.com/max/
    __ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
    / \ There's this perfect girl / Living inside the shell
    \__/ Lamya
    Erik Max Francis, Sep 8, 2003
    #6
  7. Andrew Chalk

    John Roth Guest

    Re: Ternary operator (Re: Ternery operator)

    "Michael Geary" <> wrote in message
    news:...
    > > Andrew Chalk wrote:
    > > > Is there a python equivalent of the C ternery operator?

    >
    > Peter Hansen wrote:
    > > 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.


    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
    >
    >
    John Roth, Sep 8, 2003
    #7
  8. Andrew Chalk

    Uwe Schmitt Guest

    Andrew Chalk <> wrote:
    > 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?


    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.


    --
    Dr. rer. nat. Uwe Schmitt http://www.procoders.net
    "A service to open source is a service to mankind."
    Uwe Schmitt, Sep 8, 2003
    #8
  9. Andrew Chalk

    Peter Hansen Guest

    Uwe Schmitt wrote:
    >
    > Andrew Chalk <> wrote:
    > > 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?

    >
    > 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
    Peter Hansen, Sep 8, 2003
    #9
  10. Andrew Chalk

    Gerrit Holl Guest

    Re: Ternary operator (Re: Ternery operator)

    Michael Geary wrote:
    > > Andrew Chalk wrote:
    > > > Is there a python equivalent of the C ternery operator?

    >
    > Peter Hansen wrote:
    > > 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.


    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.

    --
    219. If a physician make a large incision in the slave of a freed man,
    and kill him, he shall replace the slave with another slave.
    -- 1780 BC, Hammurabi, Code of Law
    --
    Asperger Syndroom - een persoonlijke benadering:
    http://people.nl.linux.org/~gerrit/
    Het zijn tijden om je zelf met politiek te bemoeien:
    http://www.sp.nl/
    Gerrit Holl, Sep 8, 2003
    #10
  11. Andrew Chalk

    Paul Moore Guest

    Re: Ternary operator

    Bob Gailer <> writes:

    >>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.


    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.

    >>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.


    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.
    --
    This signature intentionally left blank
    Paul Moore, Sep 8, 2003
    #11
  12. Re: Ternary operator

    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
    Skip Montanaro, Sep 8, 2003
    #12
  13. Andrew Chalk

    John Roth Guest

    Re: Ternary operator

    "Paul Moore" <> wrote in message
    news:...
    > Bob Gailer <> writes:
    >
    > >>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.

    >
    > 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.
    >
    > >>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.

    >
    > 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.

    > > 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.


    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.

    > > 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.


    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
    >
    > Paul.
    > --
    > This signature intentionally left blank
    John Roth, Sep 8, 2003
    #13
  14. Re: Ternary operator (Re: Ternery operator)

    John Roth wrote:
    > 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?)
    Michael Geary, Sep 9, 2003
    #14
  15. Andrew Chalk

    Uwe Schmitt Guest

    Peter Hansen <> wrote:
    > Uwe Schmitt wrote:
    >>
    >> Andrew Chalk <> wrote:
    >> > Is there a python equivalent of the C ternery operator?

    >>
    >> > I.e.:

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

    >>


    > 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.

    --
    Dr. rer. nat. Uwe Schmitt http://www.procoders.net
    "A service to open source is a service to mankind."
    Uwe Schmitt, Sep 9, 2003
    #15
  16. Andrew Chalk

    Peter Hansen Guest

    Uwe Schmitt wrote:
    >
    > Peter Hansen <> wrote:
    > > Uwe Schmitt wrote:
    > >>
    > >> Andrew Chalk <> wrote:
    > >> > Is there a python equivalent of the C ternery operator?
    > >>
    > >> > I.e.:
    > >>
    > >> > fred = (x == 1) ? 12 : 15
    > >>

    >
    > > 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
    Peter Hansen, Sep 9, 2003
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jakob Bieling

    Q: operator void* or operator bool?

    Jakob Bieling, Mar 5, 2004, in forum: C++
    Replies:
    2
    Views:
    560
    Rob Williscroft
    Mar 5, 2004
  2. John Smith
    Replies:
    2
    Views:
    410
    Ivan Vecerina
    Oct 6, 2004
  3. Alex Vinokur
    Replies:
    4
    Views:
    3,032
    Peter Koch Larsen
    Nov 26, 2004
  4. Michael Chermside

    RE: Ternery operator

    Michael Chermside, Sep 9, 2003, in forum: Python
    Replies:
    2
    Views:
    416
    Erik Max Francis
    Sep 9, 2003
  5. Uwe Schmitt

    AW: Ternery operator

    Uwe Schmitt, Sep 9, 2003, in forum: Python
    Replies:
    0
    Views:
    300
    Uwe Schmitt
    Sep 9, 2003
Loading...

Share This Page