(a==b) ? 'Yes' : 'No'
in [Python]
|
From: Gregory Ewing on 4 Apr 2010 20:08 Steven D'Aprano wrote: > Not according to the PEP. No fewer than 16 alternatives were put to a > vote, and with no clear winner (but many obvious losers) Guido made the > final decision. As I remember, the decision made on the basis of the vote was *not* to add a conditional expression at all, because of the fact that there was no clear winner. It was some time later that Guido suddenly announced out of the blue that he was accepting one of the choices that he had earlier said he didn't like! The ways of the BDFL are strange indeed. :-) -- Greg
From: Steven D'Aprano on 4 Apr 2010 20:19 On Mon, 05 Apr 2010 12:08:31 +1200, Gregory Ewing wrote: > Steven D'Aprano wrote: > >> Not according to the PEP. No fewer than 16 alternatives were put to a >> vote, and with no clear winner (but many obvious losers) Guido made the >> final decision. > > As I remember, the decision made on the basis of the vote was *not* to > add a conditional expression at all, because of the fact that there was > no clear winner. > > It was some time later that Guido suddenly announced out of the blue > that he was accepting one of the choices that he had earlier said he > didn't like! > > The ways of the BDFL are strange indeed. :-) I think what happened was the he got bitten by a subtle bug in the previous idiom for the ternary operator: condition and x or y will return (x if condition else y) *unless* x itself happens to be a false value. This demonstrated that the and/or idiom was not a suitable alternative to a short-circuiting ternary operator. -- Steven
From: Albert van der Horst on 6 Apr 2010 10:16 In article <houv8a$ed9$02$2(a)news.t-online.com>, Peter Otten <__peter__(a)web.de> wrote: >Pierre Quentel wrote: > >> I'm surprised nobody proposed a solution with itertools ;-) > >next(itertools.takewhile(lambda _: a == b, ["yes"]), "no") I could learn something here, if you explain it? > >You spoke to soon :) > >Peter Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
From: Albert van der Horst on 6 Apr 2010 11:02 In article <mailman.1483.1270240598.23598.python-list(a)python.org>, Steve Holden <steve(a)holdenweb.com> wrote: >kj wrote: >> In <mailman.1326.1269971785.23598.python-list(a)python.org> Steve Holden <steve(a)holdenweb.com> writes: >> >>> John Nagle wrote: >>>> Chris Rebert wrote: >>>>> On Tue, Mar 30, 2010 at 8:40 AM, gentlestone <tibor.beck(a)hotmail.com> >>>>> wrote: >>>>>> Hi, how can I write the popular C/JAVA syntax in Python? >>>>>> >>>>>> Java example: >>>>>> return (a==b) ? 'Yes' : 'No' >>>>>> >>>>>> My first idea is: >>>>>> return ('No','Yes')[bool(a==b)] >>>>>> >>>>>> Is there a more elegant/common python expression for this? >>>>> Yes, Python has ternary operator-like syntax: >>>>> return ('Yes' if a==b else 'No') >>>>> >>>>> Note that this requires a recent version of Python. >>>> Who let the dogs in? That's awful syntax. >>>> >>> Yes, that's deliberately awful syntax. Guido designed it that way to >>> ensure that people didn't aver-use it, thereby reducing the readability >>> of Python applications. >> >> Is that for real??? It's the QWERTY rationale all over again. Swell. >> >I may be misrepresenting Guido here. Unlike Tim Peters I have never >claimed to be able to channel him. > >> "Let's preserve readability by making the syntax so ugly that people >> won't use it."??? That's just perverse. (It would have been more >> reassuring if the reason had been simply that Guido has an inexplicable >> dislike of ternary expressions just like one may have an inexplicable >> dislike of Broadway musicals.) >> >I don't think his dislike of them is inexplicable. They do, when >over-used, lead to the most impenetrable code, which as a bonus is >frequently buggy. > >> First, I don't understand why ternary expressions are inherently >> hard to read, and therefore must be discouraged in the name of >> overall code readability. Sure, one can write impenetrable ternary >> expressions, but one can write impenetrable binary expressions or >> impenetrable anything else, even in Python. That the expression >> is ternary has nothing to do with it. >> >I think it does - the scope of the expressions is inherently longer when >three terms are involved rather than just tow. > >> Second, sticking the test between the two alternatives goes against >> a vast tradition in programming languages. This tradition inevitably >> fosters habits and expectations when reading code, so going against >> it automatically makes code less readable to all who were educated >> in that tradition. Consider, for example, the readability of the >> following if statement in some hypothetical language: >> >> begin: >> # this branch will be executed if test() (see below) evaluates >> # to true >> x = y + z >> a = b * x + c >> i = j - k >> p = log(q) >> if test() else: >> x = -(y + z) >> a = b * x + 2 * c >> i = j + k >> p = -log(q) >> >> If you find this hard to read (I do), the quetion is "why?". For >> me it's because, maybe through years of reading code, I've developed >> a habit that says: when you run into a fork in the logic, first >> understand what the decision hinges on. Therefore, my brain will >> start hunting for that test, and it sucks to have to find it buried >> somewhere in the middle. (Sure, one could justify this horrible >> syntax with an argument reminiscent of the one you gave for "A if >> X else B". It goes like this: long blocks of code should be avoided >> in the name of readability; this syntax discourages long blocks of >> code because one doesn't want to skip too far ahead to find that >> test. Ergo the end result is improved readability. That's just >> nuts.) >> >It's precisely to avoid that kind of lunacy that the chosen form was >adopted. Conditional expressions aren't *meant* to be complex enough to >leave any doubt about their meaning. If you require such complexity >that's perfectly OK - just use an "if" statement. Let's look at a c-example. stamp = weight>=1000 ? 120 : weight>=500 ? 100 : weight>=250 ? 80 : weight>=100 ? 60 : 44; In a glance I see that stamp gets a value. This wouldn't be so with regular if-statements that defines numerous path's through the code that each must be tested. Then I find this eminently suited to compare to a table given as a specification. What is akward is the definition of the ternary operation that is left associative to mean stamp = weight>=1000 ? 120 : ( weight>=500 ? 100 : ( weight>=250 ? 80 : ( weight>=100 ? 60 : 44 ) ) ) ; And not stamp = ((((( weight>=1000 ? 120 : weight>=500 ) ? 100 : weight>=250 ) ? 80 ... Now Python stamp =( 120 if weight>=1000 else 100 if weight>=500 else 80 if weight>=250 else 60 if weight>=100 else 44 ) This has the same advantage as c, plus : - the prices line up - there is no way to misinterpret associativity (anyway you put the brackets don't change meaning) So I like it! Old hands would have ... stamp =( weight>=1000 and 120 or weight>=500 and 100 or weight>=250 and 80 or weight>=100 and 60 or 44 ) (Kind of a brain twister, I think, inferior to C, once the c-construct is accepted as idiomatic.) <SNIP> > >regards > Steve Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert(a)spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
From: Lie Ryan on 6 Apr 2010 12:50
On 04/07/10 00:16, Albert van der Horst wrote: > In article <houv8a$ed9$02$2(a)news.t-online.com>, > Peter Otten <__peter__(a)web.de> wrote: >> Pierre Quentel wrote: >> >>> I'm surprised nobody proposed a solution with itertools ;-) >> >> next(itertools.takewhile(lambda _: a == b, ["yes"]), "no") > > I could learn something here, if you explain it? The signature for next() is: next(iterator[, default]) In particular, pay attention the `default` parameter. next() returns `default` if StopIteration is raised else it returns iterator.__next__(). takewhile(predicate, ["yes"]).__next__() return the string "yes" if predicate("yes") returns True else it raises StopIteration. The predicate (lambda _: a == b) returns True if (a == b) is True otherwise it returns False. Put the next(), takewhile(), and the predicate together and you get an a monster that returns `default` if a == b is False else "yes". |