(a==b) ? 'Yes' : 'No'
in [Python]
|
From: Steven D'Aprano on 2 Apr 2010 20:53 On Fri, 02 Apr 2010 20:12:59 +0000, kj wrote: > In <mailman.1326.1269971785.23598.python-list(a)python.org> Steve Holden > <steve(a)holdenweb.com> writes: [...] >>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. 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. http://www.python.org/dev/peps/pep-0308/ Although the results of the voting are given, unaccountably no final tally was given. Possibly because nobody could agree on how to tally the votes. Using a simple counting procedure (I give 3 votes for a rank1 vote, 2 votes for a rank2 and 1 for a rank3, signed according to whether it was an Accept or Reject vote) I find the top four candidates were: C. (if C: x else: y) 27% D. C ? x : y 20% B. if C then x else y 13% A. x if C else y 11% with everything else an order of magnitude smaller (6% or less). If you choose a different voting scheme, no doubt you will get different results. Since no candidate syntax got a majority of the vote, it came down to the only vote that really mattered: Guido's. Ankh-Morpork had dallied with many forms of government and had ended up with that form of democracy known as One Man, One Vote. The Patrician was the Man; he had the Vote. -- (T. Pratchett, "Mort") Guido did say "Note that all these are intentionally ugly" but this was followed by a smiley and was obviously tongue-in-cheek. http://mail.python.org/pipermail/python-dev/2005-September/056846.html > "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.) "Inexplicable"? They're musicals, and they're on Broadway. Surely that's two good reasons to dislike them *wink* > Second, sticking the test between the two alternatives goes against a > vast tradition in programming languages. As I've pointed out before, it is natural syntax in English. Not necessarily the most common, but common enough to be completely unexceptional: "I'll be there in ten minutes, if I can find a parking space close by, otherwise you should start without me." -- Steven
From: Steve Howell on 2 Apr 2010 23:18 On Apr 2, 5:53 pm, Steven D'Aprano <st...(a)REMOVE-THIS- cybersource.com.au> wrote: > > As I've pointed out before, it is natural syntax in English. Not > necessarily the most common, but common enough to be completely > unexceptional: > > "I'll be there in ten minutes, if I can find a parking space close by, > otherwise you should start without me." > To Steven's example, the ternary statement is a nice idiom when it emphasizes the most common results: wait_time = 10 if parking_space_close_by else expected_wait_time_in_congested_area() Or: qoutient = m / n if n else None In languages like Ruby/Perl the inverted if statement is also a useful idiom to emphasize concisely that code is exceptional in nature: def quotient(m, n) # guard code return None if n == 0 # happy path return m / n end Or: raise 'Armegeddon' if locusts_flying() useful_intelligible_happy_path_code_here()
From: John Bokma on 3 Apr 2010 13:44 Steve Howell <showell30(a)yahoo.com> writes: > In languages like Ruby/Perl the inverted if statement is also a useful > idiom to emphasize concisely that code is exceptional in nature: > > def quotient(m, n) > # guard code > return None if n == 0 > > # happy path > return m / n > end Still, in Perl I prefer: sub quotient { my ( $m, $n ) = @_; $n != 0 or return; return $m / $n; } but I guess it depends a lot on what you're used to read. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development
From: Lawrence D'Oliveiro on 3 Apr 2010 20:26 In message <mailman.1345.1269992641.23598.python-list(a)python.org>, Steve Holden wrote: > Lawrence D'Oliveiro wrote: > >> By the way, you don't need the parentheses. > > But at the same time, if you don't *absolutely know* you don't need the > parentheses ... But you can “abolutely know”—it's all spelled out here <http://docs.python.org/reference/expressions.html>. Just keep that page open every time you write Python code.
From: Steven D'Aprano on 3 Apr 2010 22:27
On Sun, 04 Apr 2010 12:26:05 +1200, Lawrence D'Oliveiro wrote: > In message <mailman.1345.1269992641.23598.python-list(a)python.org>, Steve > Holden wrote: > >> Lawrence D'Oliveiro wrote: >> >>> By the way, you don't need the parentheses. >> >> But at the same time, if you don't *absolutely know* you don't need the >> parentheses ... > > But you can “abolutely know”—it's all spelled out here > <http://docs.python.org/reference/expressions.html>. Just keep that page > open every time you write Python code. Or, when in doubt, you can add redundant parentheses. It makes no difference to the runtime, and vanishingly small difference to the compile-time, and sometimes it aids readability. Writing the absolutely minimal code necessary to do what you want is not necessarily the best approach in all cases. I find, for instance, that redundant parentheses aid readability of complex logical and arithmetic expressions, especially if you include whitespace. -- Steven |