(a==b) ? 'Yes' : 'No'
in [Python]
|
From: TomF on 31 Mar 2010 13:21 On 2010-03-31 00:57:51 -0700, Peter Otten <__peter__(a)web.de> said: > Pierre Quentel wrote: > >> I'm surprised nobody proposed a solution with itertools ;-) > > next(itertools.takewhile(lambda _: a == b, ["yes"]), "no") > > You spoke to soon :) I salute you, sir, for upholding the standards of this group. -Tom
From: Joaquin Abian on 31 Mar 2010 15:11 On Mar 31, 1:18 am, Lawrence D'Oliveiro <l...(a)geek- central.gen.new_zealand> wrote: > In message <7316f3d2-bcc9-4a1a-8598- > > cdd5d41fd...(a)k17g2000yqb.googlegroups.com>, Joaquin Abian wrote: > > (a==b) and 'YES' or 'NO' > > > Yes, ugly > > Why would you say thats ugly? > > By the way, you dont need the parentheses. Lawrence, maybe it was not the perfect adjective. I meant 'not beautiful' because for me it is not an expression I can easily read. It is not internalized in my brain. I know how to use it because I learnt how to do it time ago(in Learning Python) but always I have to think how it works (like a mental translation). For me the other alternative expresion is more readable: take_it if you_have_it else search_for_it this was already in my brain before I started writing python code. Thus, I prefer this option for my code. On the other hand, in my post, I proposed the and/or style because I found interesting how symmetrical it was with the one the OP was refering: (a==b) ? 'Yes' : 'No' (a==b) and 'Yes' or 'No' I know, I could write it without parenthesis but it seems more naturally organized with it and I read it faster and clearly. I dont know exactly why but it seems also safer to me. Joaquin
From: Den on 1 Apr 2010 11:27 On Mar 30, 10:56 am, Steve Holden <st...(a)holdenweb.com> wrote: > John Nagle wrote: > > Chris Rebert wrote: > >> On Tue, Mar 30, 2010 at 8:40 AM, gentlestone <tibor.b...(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. Speaking purely personally I hardly ever use it, > but don't dislike it. > > 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/ I've been following this thread for a few days now. My thoughts are that, in view of a long known widely used syntax for this operator, python's syntax seems like change for change sake. If current programing paradigm provides that particular trinary operator, why should python's be different from the previously well known one. For instance, no reasonable language designer would, now, use post-fix (I know about Forth) or allow only +=, -=, /=, etc. assignments ONLY. (Just as no reasonable car designer would put the accelerator pedal on the left.) There are conventions which should span products. Yes python has the trinary operator and it's not going to change, but this seems like a bit of petulance on the part of the designer. Den
From: Steve Holden on 1 Apr 2010 12:44 Den wrote: [...] > I've been following this thread for a few days now. My thoughts are > that, in view of a long known widely used syntax for this operator, > python's syntax seems like change for change sake. If current > programing paradigm provides that particular trinary operator, why > should python's be different from the previously well known one. > Because the "long known widely used syntax" has been responsible for some of the most incomprehensible and buggy code in the known universe. \ > For instance, no reasonable language designer would, now, use post-fix > (I know about Forth) or allow only +=, -=, /=, etc. assignments ONLY. > (Just as no reasonable car designer would put the accelerator pedal on > the left.) There are conventions which should span products. Yes > python has the trinary operator and it's not going to change, but this > seems like a bit of petulance on the part of the designer. > That argument could easily be extended to suggesting that there should be no new languages at all. Guido made the specific choice of this syntax precisely to try and ensure that the ternary (not trinary) operator wasn't abused the way it has been in C (and later C#). He is a language designer with a fine sense of readability, and I personally respect his decision. This StackOverflow thread http://stackoverflow.com/questions/1763543/ternary-operator-associativity-in-c-can-i-rely-on-it is just one example of the time that gets wasted. But then I suppose that this thread just exemplifies that people will find something else to waste their time on if you don't encourage them to abuse the ternary operator. 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/
From: Steven D'Aprano on 1 Apr 2010 22:33
On Thu, 01 Apr 2010 08:27:53 -0700, Den wrote about Python's ternary operator: > I've been following this thread for a few days now. My thoughts are > that, in view of a long known widely used syntax for this operator, > python's syntax seems like change for change sake. If current > programing paradigm provides that particular trinary operator, why > should python's be different from the previously well known one. Yes, I agree, we should be using the previously well known syntax: condition -> value_if_true, value_if_false which was introduced by BCPL in 1966. > For instance, no reasonable language designer would, now, use post-fix > (I know about Forth) Do you also know about Postscript, Factor, Joy and Cat, to mention only a few? And also the native language of Hewlett-Packard scientific calculators, RPL. > or allow only +=, -=, /=, etc. assignments ONLY. > (Just as no reasonable car designer would put the accelerator pedal on > the left.) There are conventions which should span products. Yes > python has the trinary operator and it's not going to change, but this > seems like a bit of petulance on the part of the designer. Unless you have read the PEP that added the operator to the language, and the reasons for rejecting the alternatives, you are not qualified to guess what Guido's motives for choosing the current syntax are. http://www.python.org/dev/peps/pep-0308/ You might not like it, but I do, and I like it far more than the ugly and hard to understand C syntax. In English (which has existed for much longer than C) the question mark punctuation symbol is a sentence terminator, not a separator between clauses, so using ? as an operator has always looked strange and disturbing to me. -- Steven |