In article <mailman.1483.1270240598.23598.python-l...@python.org>, Steve Holden <st...@holdenweb.com> wrote: >kj wrote: >> In <mailman.1326.1269971785.23598.python-l...@python.org> Steve Holden >> <st...@holdenweb.com> writes: >> >>> John Nagle wrote: >>>> Chris Rebert wrote: >>>>> On Tue, Mar 30, 2010 at 8:40 AM, gentlestone <tibor.b...@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. alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list