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. > Anyway, I don't know of any other language that puts the test > between the alternatives. No doubt there's one out there, with > emphasis on "out there"... > I understand you don't like it. The message handing down the decision is at http://mail.python.org/pipermail/python-dev/2005-September/056846.html and consideration of many applicable points in the standard library is at http://mail.python.org/pipermail/python-dev/2005-September/056803.html Disagree with the decision as you might, you can't argue that it was made with insufficient consideration of the possible alternatives or the merits of the solution. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/ -- http://mail.python.org/mailman/listinfo/python-list