449,154 Members | 1,052 Online
Need help? Post your question and get tips & solutions from a community of 449,154 IT Pros & Developers. It's quick & easy.

# [Info] PEP 308 accepted - new conditional expressions

 P: n/a Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] or C and X or Y (only if X is True) Reinhold Sep 30 '05 #1
62 Replies

 P: n/a Reinhold Birkenfeld wrote: after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] hopefully, only one of Y or X is actually evaluated ? C and X or Y (only if X is True) hopefully, "only if X is True" isn't in fact a limitation of "X if C else Y" ? /... snip comment that the natural order is C, X, Y and that programmers that care about readable code will probably want to be extremely careful with this new feature .../ Sep 30 '05 #2

 P: n/a [Fredrik] X if C else Y hopefully, only one of Y or X is actually evaluated ? Yes. From Guido's announcement at http://mail.python.org/pipermail/pyt...r/056846.html: The syntax will be A if C else B This first evaluates C; if it is true, A is evaluated to give the result, otherwise, B is evaluated to give the result. -- Richie Hindle ri****@entrian.com Sep 30 '05 #3

 P: n/a Richie Hindle writes: Yes. From Guido's announcement at http://mail.python.org/pipermail/pyt...r/056846.html: The syntax will be A if C else B Wow, I thought this was a prank at first. Congratulations to Guido. I think the introduction of list and sequence comprehensions made the absence of a conditional construct felt even more strongly than before, for those of us who program in this style. Sep 30 '05 #4

 P: n/a Fredrik Lundh wrote: Reinhold Birkenfeld wrote: after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] hopefully, only one of Y or X is actually evaluated ? (cough) Yes, sorry, it's not the same. The same would be (C and lambda:X or lambda:Y)() if I'm not much mistaken. C and X or Y (only if X is True) hopefully, "only if X is True" isn't in fact a limitation of "X if C else Y" ? /... snip comment that the natural order is C, X, Y and that programmers that care about readable code will probably want to be extremely careful with this new feature .../ Yes, that was my comment too, but I'll not demonize it before I have used it. Reinhold Sep 30 '05 #5

 P: n/a Reinhold Birkenfeld wrote: Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y Any word on chaining? That is, what would happen with the following constructs: A if B else C if D else F A if B if C else D else F The first one is the tricky bit - it could be either (A if B else C) if D else F or A if B else (C if D else F) I'd expect the former from left-> right semantics, but reading the unparenthesized form, I'd see "A if B else ..." note that B is true, and conclude the expression evaluated to A (which would be wrong if D is false). Sep 30 '05 #6

 P: n/a Reinhold Birkenfeld wrote: after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y Hooray! After years of arguing over which syntax to use, and finally giving up since nobody could agree, the Benevolent Dictator did what only a dictator can do, and just made a damn decision already. Thank you, Guido! =) Dave Sep 30 '05 #7

 P: n/a Rocco Moretti wrote: Reinhold Birkenfeld wrote: Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y Any word on chaining? That is, what would happen with the following constructs: A if B else C if D else F A if B if C else D else F The first one is the tricky bit - it could be either (A if B else C) if D else F or A if B else (C if D else F) I'd expect the former from left-> right semantics, but reading the unparenthesized form, I'd see "A if B else ..." note that B is true, and conclude the expression evaluated to A (which would be wrong if D is false). It will be A if B else (C if D else F). Quote: """ The priorities will be such that you can write x = A if C else B x = lambda: A if C else B x = A if C else B if D else E But you'd have to write if (A if C else B): [x for x in seq if (A if C else B)] A if (X if C else Y) else B (A if C else B) if D else E Note that all these are intentionally ugly. :) """ Reinhold Sep 30 '05 #8

 P: n/a Reinhold Birkenfeld wrote: X if C else Y Oh well. Just about any conditional is better than no conditional. Carl Banks Sep 30 '05 #9

 P: n/a Dave Benjamin wrote: Hooray! After years of arguing over which syntax to use, and finally giving up since nobody could agree, the Benevolent Dictator did what only a dictator can do, and just made a damn decision already. Thank you, Guido! =) Yes, hear hear. So what made him change his mind? When the debates raged over PEP 308, he seemed pretty dead set against it (at least by proxy) ... -- Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis The great artist is the simplifier. -- Henri Amiel Sep 30 '05 #10

 P: n/a Reinhold Birkenfeld writes: Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] What's wrong with "C ? X:Y"? Aside from ":" being overloaded? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQBDPcH9x9p3GYHlUOIRAlVHAJ9zgyxICMojsZtKCimAzA 8w0ILYvACfWqxv iWsn3baqRydINp8eYjStR18= =XWo0 -----END PGP SIGNATURE----- Sep 30 '05 #11

 P: n/a Reinhold Birkenfeld wrote: Rocco Moretti wrote:Reinhold Birkenfeld wrote:Hi,after Guido's pronouncement yesterday, in one of the next versions of Pythonthere will be a conditional expression with the following syntax:X if C else YAny word on chaining?That is, what would happen with the following constructs:A if B else C if D else FA if B if C else D else FThe first one is the tricky bit - it could be either(A if B else C) if D else ForA if B else (C if D else F)I'd expect the former from left-> right semantics, but reading theunparenthesized form, I'd see "A if B else ..." note that B is true, andconclude the expression evaluated to A (which would be wrong if D is false). It will be A if B else (C if D else F) So this evaluates as if there are parentheses around each section.. Hmm? (A) if (B) else ( (C) if (D) else (F) ) The first 'if' divided the expr, then each succeeding 'if' divides the sub expressions, etc... ? So ... A if B else C + X * Y Would evaluate as... ? A if B else (C + X * Y) and... value = X * Y + A if B else C would be ? value = (X * Y + A) if B else C or ? value = X * Y + (A if B else C) I think I'm going to make it a habit to put parentheses around these things just as if they were required. Cheers, Ron Sep 30 '05 #12

 P: n/a On 9/30/05, Sam wrote: Reinhold Birkenfeld writes: Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] What's wrong with "C ? X:Y"? Aside from ":" being overloaded? First thing that comes to my mind is that it is more C-ish (read cryptic) than pythonic (read elegant and understandable). jw Sep 30 '05 #13

 P: n/a On Fri, 30 Sep 2005 20:25:35 +0200, Reinhold Birkenfeld wrote: Fredrik Lundh wrote: Reinhold Birkenfeld wrote: after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] hopefully, only one of Y or X is actually evaluated ?(cough) Yes, sorry, it's not the same. The same would be(C and lambda:X or lambda:Y)()if I'm not much mistaken. I think you need to parenthesize, but also note that using lambda does not always grab the currently-executing-scope X or Y, so I think the list container idiom may be better to show the semantics of the new expression: X='this is global X' Y='this is global Y' C=False def foo(): ... C = True ... class K(object): ... X='this is K.X' ... Y='this is K.Y' ... cv = (C and (lambda:X) or (lambda:Y))() ... return K ... def bar(): ... C = True ... class K(object): ... X='this is K.X' ... Y='this is K.Y' ... cv = (C and [X] or [Y])[0] ... return K ... foo().cv 'this is global X' bar().cv 'this is K.X' C and X or Y (only if X is True) hopefully, "only if X is True" isn't in fact a limitation of "X if C else Y" ? /... snip comment that the natural order is C, X, Y and that programmers that care about readable code will probably want to be extremely careful with this new feature .../Yes, that was my comment too, but I'll not demonize it before I have used it. Me too ;-) Regards, Bengt Richter Oct 1 '05 #14

 P: n/a "Dave Benjamin" > Hooray! After years of arguing over which syntax to use, and finally giving up since nobody could agree, I understand that this has become the local 'politically correct' view, but as a participant in the discussion, I know it not true and actively deceptive. The community was prevented from coming to a decision. There was a 'primary' vote with an incumbent, 15 challengers, and several write-ins. But there was no runoff. As recorded in http://www.python.org/peps/pep-0308.html, the incumbent proposal, Guido's favorite from beginning to end, x if C else y, was tied for 1st in rejections and was only 4th in acceptances, being beaten by (if C: x else: y) (which was also first in rejections) C ? x : y if C then x else y Among the other proposals also, about 3/4ths had the order C x y. I think if nothing else, the vote showed that the community pretty strongly preferred the order C x y to x C y. I am pretty sure that a vote then (and probably now) on that specific issue would have favored the first. But that idea, along with any runoff among the best exemplars of each order, was *rejected*, along with notice that 'unofficial' votes conducted by community members would be ignored. The discussion and decision process was also inhibited by the lack of any ground rules as to what would be an acceptible candidate. So there was lots of confusion and lots of time wasted on 'favorite son' candidates that had no chance of winning (much as there once was on the first round of voting at American presidential nominating conventions). There was also, that I knew of, no definition of success nor a process aimed at success. I doubt that many actually expected the obviously preliminary vote to reach a definitive conclusion. Even in the recent py-dev discussion, Guido declined, when I specifically asked, to reveal his 'ballot' of alternatives he was considering. So what were we actually supposed to discuss? Naturally, there followed irrelevant noise posts on impossible alternatives and peripheral issues. And this became a reason for Guido to 'just decide' on his original favorite, no explanation offered. ---------- The lesson for me is to spend much less time on Python discussion and much more on unfinished projects. So even if I never use the new syntax, I will have gained something ;-) Terry J. Reedy Oct 1 '05 #15

 P: n/a Jaime Wyant writes: On 9/30/05, Sam wrote: Reinhold Birkenfeld writes: > Hi, > > after Guido's pronouncement yesterday, in one of the next versions of Python > there will be a conditional expression with the following syntax: > > X if C else Y > > which is the same as today's > > (Y, X)[bool(C)] What's wrong with "C ? X:Y"? Aside from ":" being overloaded? First thing that comes to my mind is that it is more C-ish (read cryptic) than pythonic (read elegant and understandable). And "foo if bar" is Perl-ish; yet, even Perl has the ? : operators. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQBDPgkyx9p3GYHlUOIRAtYJAJ94v5hK3gZlSGTILzXguQ Ns4ct2dQCfZT7V ZNafvlzn6LAlelGerLV9vH8= =xsEg -----END PGP SIGNATURE----- Oct 1 '05 #16

 P: n/a Terry Reedy ha scritto: "Dave Benjamin" > Hooray! After years of arguing over which syntax to use, and finally giving up since nobody could agree, I understand that this has become the local 'politically correct' view, but as a participant in the discussion, I know it not true and actively deceptive. The community was prevented from coming to a decision. There was a 'primary' vote with an incumbent, 15 challengers, and several write-ins. But there was no runoff. FWIW, I think Terry's recollection is pretty close to the "historical truth". Guido could have decided two years ago, sparing us the PEP 308 ordalia. So, I am happy that at the end we will have a conditional operator, but I am not happy of how the process worked out. It was just an enormous waste of resources that could have been employed much better :-( Michele Simionato Oct 1 '05 #17

 P: n/a Ron Adam wrote: It will be A if B else (C if D else F) So this evaluates as if there are parentheses around each section.. Hmm? (A) if (B) else ( (C) if (D) else (F) ) The first 'if' divided the expr, then each succeeding 'if' divides the sub expressions, etc... ? So ... A if B else C + X * Y Would evaluate as... ? A if B else (C + X * Y) and... value = X * Y + A if B else C would be ? value = (X * Y + A) if B else C or ? value = X * Y + (A if B else C) I think I'm going to make it a habit to put parentheses around these things just as if they were required. Yes, that's the best way to make it readable and understandable. Reinhold Oct 1 '05 #18

 P: n/a Erik Max Francis wrote: Dave Benjamin wrote: Hooray! After years of arguing over which syntax to use, and finally giving up since nobody could agree, the Benevolent Dictator did what only a dictator can do, and just made a damn decision already. Thank you, Guido! =) Yes, hear hear. So what made him change his mind? When the debates raged over PEP 308, he seemed pretty dead set against it (at least by proxy) ... Raymond Hettinger proposed to change the behavior of and/or to return one of their arguments because he had been bitten by the common trap of C and X or Y when X is False. People were positive about it, but said that then a conditional would have to be introduced. So Guido considered it again. He says himself that the greatest problem last time was that no consensus over syntax was reached, and he solved the problem this time by deciding himself. Reinhold Oct 1 '05 #19

 P: n/a Sam wrote: Jaime Wyant writes: On 9/30/05, Sam wrote: Reinhold Birkenfeld writes: > Hi, > > after Guido's pronouncement yesterday, in one of the next versions of Python > there will be a conditional expression with the following syntax: > > X if C else Y > > which is the same as today's > > (Y, X)[bool(C)] What's wrong with "C ? X:Y"? Aside from ":" being overloaded? First thing that comes to my mind is that it is more C-ish (read cryptic) than pythonic (read elegant and understandable). And "foo if bar" is Perl-ish; yet, even Perl has the ? : operators. Perl's "foo if bar" is very different to this one, you should know about this. For a conditional, syntax must be found, and the tradition of Python design is not to use punctuation for something that can be solved with keywords. Reinhold Oct 1 '05 #20

 P: n/a Reinhold Birkenfeld writes: For a conditional, syntax must be found, and the tradition of Python design is not to use punctuation for something that can be solved with keywords. Yeah, "if C then A else B" is a ancient tradition stretching from Algol-60 to OCAML, and who knows what all else in between. I'm not sure what Guido saw in the "A if C else B" syntax but it's not a big deal. Oct 1 '05 #21

 P: n/a Sam wrote: And "foo if bar" is Perl-ish; yet, even Perl has the ? : operators. What _isn't_ Perl-ish? Oct 1 '05 #22

 P: n/a "Michele Simionato" writes: [...] Guido could have decided two years ago, sparing us the PEP 308 ordalia. So, I am happy that at the end we will have a conditional operator, but I am not happy of how the process worked out. It was just an enormous waste of resources that could have been employed much better :-( Seems that's what Guido thinks too: http://mail.python.org/pipermail/pyt...er/056561.html | If there's one thing I've learned from the PEP 308 vote, it is that | votes for language don't work. I prefer some discussion on Python-dev | after which I pick one. I think he said at the time that it was an experiment. John Oct 1 '05 #23

 P: n/a Leif K-Brooks writes: Sam wrote: And "foo if bar" is Perl-ish; yet, even Perl has the ? : operators. What _isn't_ Perl-ish? BASIC? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.7 (GNU/Linux) iD8DBQBDPqJwx9p3GYHlUOIRAnrgAJ4vgWBuiS8E9vq93mQSuX vJ2OBtAwCeMeR0 CemAKp04FEQ3vlz0LFoY1Go= =IP0a -----END PGP SIGNATURE----- Oct 1 '05 #24

 P: n/a Reinhold Birkenfeld wrote: Ron Adam I think I'm going to make it a habit to put parentheses around thesethings just as if they were required. Yes, that's the best way to make it readable and understandable. Reinhold Now that the syntax is settled, I wonder if further discussion on the contextual behavior could be done? Or maybe it was already done off line or in private email? To me the advantage of a if b else c form is the easy chaining to build up a sum of conditional parts, where each next part is dependent on the previous result. The advantage of the nested form, is it can be used in place of an if-elif-else structure. But I think the (a if b else c) syntax doesn't match that behavior very well so I was expecting the default behavior to be the sequential chaining and not nested evaluation. But of course, by explicitly placing parentheses, you can do either. Cheers, Ron Oct 1 '05 #25

 P: n/a On Fri, 30 Sep 2005 21:28:26 -0400 Terry Reedy wrote: The lesson for me is to spend much less time on Python discussion and much more on unfinished projects. So even if I never use the new syntax, I will have gained something ;-) QOTW? -- jk Oct 1 '05 #26

 P: n/a Rocco Moretti wrote: That is, what would happen with the following constructs: A if B else C if D else F A if B if C else D else F The correct answer should be the person who wrote it would get told off for writing code that a person reading would have no idea what the code was doing (without understanding the precedence). Whilst it's good to have clear understandable, well defined rules for these things, that's no excuse for having unreadable code that other people can't read and understand without having to remember obscure rules. Personally, I'd hope that any code-linting tools would flag such expressions as potentially bad because they're not clear. (Whereas bracketed expressions instantly help here). Best Regards, Michael Oct 3 '05 #27

 P: n/a Paul Rubin wrote: I'm not sure what Guido saw in the "A if C else B" syntax but it's not a big deal. Maybe Guido's done some perl programming on the side? When I've been doing perl programming I've quite liked the .... if (...); construct, however, on occasion it's been desirable to have an else there. By having an else there it means you don't need the ?: syntax and can just have one syntax. On the flipside, people with different mother tongues often have a different way of using language. (eg lots of non-native english speakers speaking better english than those with english as their mother tongue :-) And sometimes that different way can be better ? Direct translation of german grammatical form for example - resulting in something looking like yoda speak... Personally I like this form :) Regards, Michael. Oct 3 '05 #28

 P: n/a Fredrik Lundh wrote: /... snip comment that the natural order is C, X, Y and that programmers that care about readable code will probably want to be extremely careful with this new feature .../ That's also my opinion, but OTOH, Guido's syntax is more close to the syntax of list comprehensions. Greets, Volker -- Volker Grabsch ---<<(())>>--- \frac{\left|\vartheta_0\times\{\ell,\kappa\in\Re\} \right|}{\sqrt [G]{-\Gamma(\alpha)\cdot\mathcal{B}^{\left[\oint\!c_\hbar\right]}}} Oct 3 '05 #29

 P: n/a Op 2005-09-30, Sam schreef : This is a MIME GnuPG-signed message. If you see this text, it means that your E-mail or Usenet software does not support MIME signed messages. The Internet standard for MIME PGP messages, RFC 2015, was published in 1996. To open this message correctly you will need to install E-mail or Usenet software that supports modern Internet standards. --=_mimegpg-commodore.email-scan.com-32420-1128120829-0002 Content-Type: text/plain; format=flowed; charset="US-ASCII" Content-Disposition: inline Content-Transfer-Encoding: 7bit Reinhold Birkenfeld writes: Hi, after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y which is the same as today's (Y, X)[bool(C)] What's wrong with "C ? X:Y"? Aside from ":" being overloaded? Nothing, but afaiu Guido dislikes it. -- Antoon Pardon Oct 3 '05 #30

 P: n/a Michael a écrit : Rocco Moretti wrote:That is, what would happen with the following constructs:A if B else C if D else FA if B if C else D else F The correct answer should be the person who wrote it would get told off for writing code that a person reading would have no idea what the code was doing (without understanding the precedence). Whilst it's good to have clear understandable, well defined rules for these things, that's no excuse for having unreadable code that other people can't read and understand without having to remember obscure rules. Personally, I'd hope that any code-linting tools would flag such expressions as potentially bad because they're not clear. (Whereas bracketed expressions instantly help here). Actually, you don't need to know operator precedence here because the notation isn't ambiguous in those 2 examples. Of course, it takes some time to understand the thing but it has more to do with the excessive amount of "logic" in one line than with the syntax. Oct 3 '05 #31

 P: n/a Ron Adam wrote:So ... A if B else C + X * YWould evaluate as... ? A if B else (C + X * Y) """In general, 'if' and 'else' bind less tight than everything except lambda.""" http://mail.python.org/pipermail/pyt...er/056846.html -- \S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/ ___ | "Frankly I have no feelings towards penguins one way or the other" \X/ | -- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump Oct 3 '05 #32

 P: n/a Christophe wrote: Michael a Ã©crit : Rocco Moretti wrote:That is, what would happen with the following constructs:A if B else C if D else FA if B if C else D else F The correct answer should be the person who wrote it would get told off for writing code that a person reading would have no idea what the code was doing (without understanding the precedence). Whilst it's good to have clear understandable, well defined rules for these things, that's no excuse for having unreadable code that other people can't read and understand without having to remember obscure rules. Personally, I'd hope that any code-linting tools would flag such expressions as potentially bad because they're not clear. (Whereas bracketed expressions instantly help here). Actually, you don't need to know operator precedence here because the notation isn't ambiguous in those 2 examples. Of course, it takes some time to understand the thing but it has more to do with the excessive amount of "logic" in one line than with the syntax. I noted that. However it *does* slow people down which increases the chances of misconception (which is why I'd be in favour of bracketing these expressions). Michael. Oct 3 '05 #33

 P: n/a On Monday 03 October 2005 03:48 am, Volker Grabsch wrote: Fredrik Lundh wrote: /... snip comment that the natural order is C, X, Y and that programmers that care about readable code will probably want to be extremely careful with this new feature .../ That's also my opinion, but OTOH, Guido's syntax is more close to the syntax of list comprehensions. GvR's syntax has the advantage of making grammatical sense in English (i.e. reading it as written pretty much makes sense). -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Oct 7 '05 #34

 P: n/a As mentioned earlier only a dictator can make such decisions and of course as with many dictatorships the wrong decision is often made. There's no such thing as a benevolent dictatorship. -- Robin Becker Oct 7 '05 #35

 P: n/a Robin Becker wrote: As mentioned earlier only a dictator can make such decisions and of course as with many dictatorships the wrong decision is often made. There's no such thing as a benevolent dictatorship. Ever cared to check what committees can do to a language ;-) --eric Oct 7 '05 #36

 P: n/a On Friday 07 October 2005 08:56, Eric Nieuwland wrote: Ever cared to check what committees can do to a language ;-) *has nasty visions of Java* Hey! Stop that! - Michael Oct 7 '05 #37

 P: n/a On 07/10/05, Eric Nieuwland wrote: Ever cared to check what committees can do to a language ;-) +1 QOTW. -- Cheers, Simon B, si***@brunningonline.net, http://www.brunningonline.net/simon/blog/ Oct 7 '05 #38

 P: n/a Terry Hancock wrote: GvR's syntax has the advantage of making grammatical sense in English (i.e. reading it as written pretty much makes sense). as a native Python speaker, I find that argument being remarkably weak. things I write in Python should make sense in Python, not in some other language. (besides, we already have way too many languages designed by self-proclaimed linguists) Oct 7 '05 #39

 P: n/a Eric Nieuwland wrote: Ever cared to check what committees can do to a language ;-) ..... well there goes democracy :( -the happy slaves eat and are contented-ly yrs- Robin Becker Oct 7 '05 #40

 P: n/a On Friday 07 October 2005 10:52 am, Fredrik Lundh wrote: Terry Hancock wrote: GvR's syntax has the advantage of making grammatical sense in English (i.e. reading it as written pretty much makes sense). as a native Python speaker, I find that argument being remarkably weak. things I write in Python should make sense in Python, not in some other language. Well, since this is adopted as the Python grammar, then I guess it will make sense in Python too, won't it? But English grammar is already strongly represented in Python's choices, so it's entirely consistent to do it here, too (otherwise, explain "not in"). -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Oct 7 '05 #41

 P: n/a On Fri, 07 Oct 2005 18:24:28 +0100, Robin Becker wrote: Eric Nieuwland wrote: Ever cared to check what committees can do to a language ;-) .... well there goes democracy :( For fans of Terry Pratchett's Discworld series, there is: Vimes had once discussed the Ephebian idea of 'democracy' with Carrot, and had been rather interested in the idea that everyone had a vote until he found out that while he, Vimes, would have a vote, there was no way in the rules that anyone could prevent Nobby Nobbs from having one as well. Vimes could see the flaw there straight away. -- The Fifth Elephant -- Steven. Oct 8 '05 #42

 P: n/a On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock wrote:GvR's syntax has the advantage of making grammatical sense in English (i.e.reading it as written pretty much makes sense). I know, let's re-write Python to make it more like COBOL! That's bound to be a winner! -- Email: zen19725 at zen dot co dot uk Oct 9 '05 #43

 P: n/a On Sunday 09 October 2005 07:50 am, phil hunt wrote: On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock wrote:GvR's syntax has the advantage of making grammatical sense in English (i.e.reading it as written pretty much makes sense). I know, let's re-write Python to make it more like COBOL! That's bound to be a winner! Whereas the "natural order" of "condition affirmative negative" is natural for what reason? That it is so in C? I don't find that so compelling either, frankly. Why should it really matter in the end? I've always found C's order (and punctuation) confusing, I have to look it up practically everytime I use it or have to read it (which correlates to it being used very rarely, with causality in both directions). Given that situation, choosing a form which is easy to read is surely an advantage, and, since it is the way that Python has handled logic in the past, it makes sense to continue doing so. No doubt, ANY choice of ternary operator for Python will be criticized, and no doubt, ANY choice would nevertheless be usable. OTOH, I think this choice is consistent with the rest of Python's design. The general choice to use keyword operators for LOGIC and symbolic operators for MATH is retained, and so long as we're describing the logic in words, it makes sense for the wording to sound natural. Consistency certainly does make it easier for me to remember. Python's main advantage over other languages, for me, is that it makes me run to the manual a lot less, and I generally don't get confused trying to follow other people's code. -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com Oct 10 '05 #44

 P: n/a On 9/30/05, Reinhold Birkenfeld wrote: after Guido's pronouncement yesterday, in one of the next versions of Python there will be a conditional expression with the following syntax: X if C else Y I don't understand why there is a new expression, if this could be accomplished with: if C: X else: Y What is the advantage with the new expression? -- La web sin popups ni spyware: Usa Firefox en lugar de Internet Explorer Oct 11 '05 #46

 P: n/a Sebastian Bassi wrote: I don't understand why there is a new expression, if this could be accomplished with: if C: X else: Y What is the advantage with the new expression? It actually is an expression, whereas your example shows a statement (so "this" could _not_ be accomplished with what you showed). -Peter Oct 11 '05 #47

 P: n/a "Dave Hansen" wrote: On Mon, 10 Oct 2005 16:42:34 -0500, Terry Hancock wrote:On Sunday 09 October 2005 07:50 am, phil hunt wrote: On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock wrote: >GvR's syntax has the advantage of making grammatical sense in English (i.e. >reading it as written pretty much makes sense). I know, let's re-write Python to make it more like COBOL! That's bound to be a winner!Whereas the "natural order" of "condition affirmative negative" is naturalfor what reason? That it is so in C? And Basic, and Fortran, and Lisp, and just about any programming language you care to name, including python (if Condition: Affirmative else: Negative). Block delimiters (curly braces, if/fi, begin/end, etc.) are also in just about any language but this didn't stop python using indentation instead, so what's your point ? Conformity and backwards compatibility should not be top priorities in language design; fortunately for python, they're not. George Oct 11 '05 #48

 P: n/a Dave Hansen wrote: And Basic, and Fortran, and Lisp, and just about any programming language you care to name, including python (if Condition: Affirmative else: Negative). Not to mention that the sequence is identical to execution order. It's just plain goofy to have to scan to the middle of an expression to find out what happens first, then depending on the result of that, skipping back over what you just skipped. 1 word: Perl FWIW, in over 20 years of C programming, I use it pretty rarely too, though I never had to look it up after I first saw it in K&R. It only very rarely holds any advantage over a simple if/else statement, especially in modern compilers. It's most useful in macros, which python doesn't even have. same time span and I used it zillions of times ==eric Oct 11 '05 #49

 P: n/a Op 2005-10-10, Terry Hancock schreef : On Sunday 09 October 2005 07:50 am, phil hunt wrote: On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock wrote: >GvR's syntax has the advantage of making grammatical sense in English (i.e. >reading it as written pretty much makes sense). I know, let's re-write Python to make it more like COBOL! That's bound to be a winner! Whereas the "natural order" of "condition affirmative negative" is natural for what reason? That it is so in C? I don't find that so compelling either, frankly. Why should it really matter in the end? I've always found C's order (and punctuation) confusing, I have to look it up practically everytime I use it or have to read it (which correlates to it being used very rarely, with causality in both directions). Given that situation, choosing a form which is easy to read is surely an advantage, and, since it is the way that Python has handled logic in the past, it makes sense to continue doing so. Personnaly I would think some consistency between conditional expressions and conditional statements would have been a good thing. I haven't seen a discussion where the following kind of if statement was discussed. do: return a[0] if a[0] < a[1] else: return a[1[ No doubt, ANY choice of ternary operator for Python will be criticized, and no doubt, ANY choice would nevertheless be usable. Agreed, I think having it is more important than what form it comes in. My preference has more to do with consistency with the statement. OTOH, I think this choice is consistent with the rest of Python's design. The general choice to use keyword operators for LOGIC and symbolic operators for MATH is retained, and so long as we're describing the logic in words, it makes sense for the wording to sound natural. Consistency certainly does make it easier for me to remember. I think that a consistency within the language would have made more sense than consistency with someone's mother tongue. When I program I program in python or some other programming language. Not in english, dutch, french or some other natural language. But for me this is just style talk. I don't care that much for style, I'm more concerned with functionality and I'm glad this functionality will become available. -- Antoon Pardon Oct 11 '05 #50

62 Replies

### This discussion thread is closed

Replies have been disabled for this discussion.