Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Ternery operator

Reply
Thread Tools

Ternery operator

 
 
Paul Moore
Guest
Posts: n/a
 
      09-08-2003
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
 
Reply With Quote
 
 
 
 
Skip Montanaro
Guest
Posts: n/a
 
      09-08-2003

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/v.../nondist/peps/

Skip

 
Reply With Quote
 
 
 
 
John Roth
Guest
Posts: n/a
 
      09-08-2003

"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



 
Reply With Quote
 
Michael Geary
Guest
Posts: n/a
 
      09-09-2003
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?)


 
Reply With Quote
 
Uwe Schmitt
Guest
Posts: n/a
 
      09-09-2003
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."
 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      09-09-2003
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
operator*(Foo) and operator*(int) const: ISO C++ says that these are ambiguous: Alex Vinokur C++ 4 11-26-2004 11:46 PM
Operator overloading on "default" operator John Smith C++ 2 10-06-2004 10:22 AM
Q: operator void* or operator bool? Jakob Bieling C++ 2 03-05-2004 04:27 PM
RE: Ternery operator Michael Chermside Python 2 09-09-2003 07:21 PM
AW: Ternery operator Uwe Schmitt Python 0 09-09-2003 12:43 PM



Advertisments
 



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57