469,293 Members | 1,319 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,293 developers. It's quick & easy.

[Info] PEP 308 accepted - new conditional expressions

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
62 2914
Paul Rubin <http://ph****@nospam.invalid> wrote:
Reinhold Birkenfeld <re************************@wolke7.net> 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.


Perhaps, he's preparing Python for the eventual absorption into Perl7.

--
William Park <op**********@yahoo.ca>, Toronto, Canada
ThinFlash: Linux thin-client on USB key (flash) drive
http://home.eol.ca/~parkw/thinflash.html
BashDiff: Super Bash shell
http://freshmeat.net/projects/bashdiff/
Oct 12 '05 #51
>>>>> "Sebastian" == Sebastian Bassi <sb****@gmail.com> writes:

Sebastian> On 9/30/05, Reinhold Birkenfeld <re************************@wolke7.net> 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


Sebastian> I don't understand why there is a new expression, if
Sebastian> this could be accomplished with:

Sebastian> if C: X else: Y

Sebastian> What is the advantage with the new expression?

One very frequent use case is building a string.
Instead of:

if X==0:
filler="yes"
else:
filler="no"
return "the answer is %s" % filler
What I really want to do is take four lines of conditional, and put
them into one, as well as blow off dealing with a 'filler' variable:

return "the answer is " + "yes" if X==0 else "no"
Or whatever the final release syntax is.
Conditional expressions are a nice way to shim something in place, on
an acute basis. Chronic use of them could lead to a full-on plate of
spaghetti, where you really wanted code.
They can be impenitrable. Whenever I'm dealing with them in C/C++, I
always line the ?, the :, and the ; characters vertically, which may
seem a bit excessive in terms of whitespace, but provides a nice
hieroglyph over on the right side of the screen, to make things
obvious.
Best,
Chris
Oct 12 '05 #52
>>>>> Paul Rubin <http://ph****@NOSPAM.invalid> (PR) wrote:
PR> Reinhold Birkenfeld <re************************@wolke7.net> 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.
PR> Yeah, "if C then A else B" is a ancient tradition stretching from
PR> Algol-60 to OCAML, and who knows what all else in between. I'm not
PR> sure what Guido saw in the "A if C else B" syntax but it's not a big deal.


I suspect it is because "if C then A else B" gives problems in the parser
because it would have difficulty to distinguish this in time from the if
statement. This is because the parser doesn't use a very strong formalism.

I think language design should prevail over parsing problems, but in this
case it is probably a pragmatic argument that wins.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org
Oct 12 '05 #53
Chris Smith wrote:
What I really want to do is take four lines of conditional, and put
them into one, as well as blow off dealing with a 'filler' variable:

return "the answer is " + "yes" if X==0 else "no"
Or whatever the final release syntax is.
The syntax is fine, but the semantics might not be what you expected. If I
understand it correctly you need:

return "the answer is " + ("yes" if X==0 else "no")

Guido's pronouncement said:
In general, 'if' and 'else' bind less tight than everything except
lambda.

Oct 12 '05 #54
On Tue, 11 Oct 2005 01:06:30 -0400, "George Sakkis"
<gs*****@rutgers.edu> wrote:
"Dave Hansen" <id**@hotmail.com> wrote:
On Mon, 10 Oct 2005 16:42:34 -0500, Terry Hancock
<ha*****@anansispaceworks.com> wrote:
>On Sunday 09 October 2005 07:50 am, phil hunt wrote:
>> On Fri, 7 Oct 2005 01:05:12 -0500, Terry Hancock <ha*****@anansispaceworks.com> 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?
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


The point is order of execution. The condition is tested first, so it
should appear first. I can think of no other language besides Perl
where that is not the case. Admittedly, I don't know every other, or
even a large number, of other languages.
compatibility should not be top priorities in language design; fortunately for python, they're not.


Conformity I'd agree with, backwards capatibility I strongly disagree.
Breaking existing programs is a Bad Thing(tm). All the code I wrote
for Python 1.52 still seems to work in 2.4.

Regards,

-=Dave
--
Change is inevitable, progress is not.
Oct 12 '05 #55
On Wed, 12 Oct 2005 13:02:20 +0200, Piet van Oostrum <pi**@cs.uu.nl>
wrote:
>> Paul Rubin <http://ph****@NOSPAM.invalid> (PR) wrote:

[...]
PR> Yeah, "if C then A else B" is a ancient tradition stretching from
PR> Algol-60 to OCAML, and who knows what all else in between. I'm not
PR> sure what Guido saw in the "A if C else B" syntax but it's not a big deal.


I suspect it is because "if C then A else B" gives problems in the parser
because it would have difficulty to distinguish this in time from the if
statement. This is because the parser doesn't use a very strong formalism.


So lose the "if."

R = C then A else B

I don't think python uses the question mark for anything. Throw that
in, if it makes parsing easier:

R = C ? then A else B

Regards,

-=Dave
--
Change is inevitable, progress is not.
Oct 12 '05 #56
Chris Smith <sm*************@bigfoot.com> wrote:
What I really want to do is take four lines of conditional, and put
them into one, as well as blow off dealing with a 'filler' variable:

return "the answer is " + "yes" if X==0 else "no"


I would write this as:

return "the answer is " + ("yes" if X==0 else "no")

Adding the parens makes it clearer. I've long since given up trying
to remember operator precedence (except for the most basic like
multiplication is stronger than addition) and use parens with wild
abandon.
Oct 12 '05 #57
Dave Hansen wrote:
So lose the "if."

R = C then A else B


It would be nice (in my opinion) if this were the way it was going to
be. Having one of the two results come first makes that result seem
somehow of primary importance, while the conditional (which in my mind
is far more important than either result) comes hidden in the middle:

"C then A else B" makes the conditional stand out

"A if C else B" suggests that A is more important than B and hides C

But I can live with whichever it is... not that I have any choice. :)

-Peter
Oct 12 '05 #58
>>>>> id**@hotmail.com (Dave Hansen) (DH) wrote:
DH> So lose the "if." DH> R = C then A else B DH> I don't think python uses the question mark for anything. Throw that
DH> in, if it makes parsing easier: DH> R = C ? then A else B


We have already had this discussion several times. I don't think it is
going to add anything new to it. Besides after the BDFL has decided it is
useless.
--
Piet van Oostrum <pi**@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: pi**@vanoostrum.org
Oct 13 '05 #59
On Thu, 13 Oct 2005 21:49:15 +0200, Piet van Oostrum <pi**@cs.uu.nl>
wrote:
>> id**@hotmail.com (Dave Hansen) (DH) wrote:

DH> So lose the "if."

DH> R = C then A else B

DH> I don't think python uses the question mark for anything. Throw that
DH> in, if it makes parsing easier:

DH> R = C ? then A else B


We have already had this discussion several times. I don't think it is
going to add anything new to it. Besides after the BDFL has decided it is
useless.


Oh, agreed, most assuredly (except that "we" didn't include "me," not
that that would have made any difference, but I missed most of the
discussion). I was merely responding to your assertion that using "if
C then A else B" could cause parsing problems.

I'm not convinced python even needs a ternary operator. I just wish
the syntax chosen by the BDFL made more sense. Even if I don't use
it, I'll likely have to read it...

Regards,

-=Dave
--
Change is inevitable, progress is not.
Oct 13 '05 #60
>>>>> "Duncan" == Duncan Booth <du**********@invalid.invalid> writes:

Duncan> Chris Smith wrote:
What I really want to do is take four lines of conditional, and
put them into one, as well as blow off dealing with a 'filler'
variable:

return "the answer is " + "yes" if X==0 else "no"
Or whatever the final release syntax is.
Duncan> The syntax is fine, but the semantics might not be what
Duncan> you expected. If I understand it correctly you need:

Duncan> return "the answer is " + ("yes" if X==0 else "no")

Duncan> Guido's pronouncement said:
In general, 'if' and 'else' bind less tight than everything
except lambda.

I say, with the utmost arrogance, that I won't neglect the parens more
than, say, 50 times. ;)
-Chris
Oct 14 '05 #61
On Wed, 12 Oct 2005 02:15:40 -0400, Chris Smith <sm*************@bigfoot.com> wrote:
>> "Sebastian" == Sebastian Bassi <sb****@gmail.com> writes:
Sebastian> On 9/30/05, Reinhold Birkenfeld <re************************@wolke7.net> 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

Sebastian> I don't understand why there is a new expression, if
Sebastian> this could be accomplished with:

Sebastian> if C: X else: Y

Sebastian> What is the advantage with the new expression?

One very frequent use case is building a string.

But what you show doesn't require choice of which to _evaluate_,
since you are merely choosing between immutable constants, and there is
no side effect or computation overhead to avoid by not evaluating
the unselected expression. So

"the answer is " + ('no', 'yes')[X==0]

would do as well.
Instead of:

if X==0:
filler="yes"
else:
filler="no"
return "the answer is %s" % filler
What I really want to do is take four lines of conditional, and put
them into one, as well as blow off dealing with a 'filler' variable:

return "the answer is " + "yes" if X==0 else "no" As has been pointed out, though legal there is some doubt as to whether
you meant what you wrote ;-)

Or whatever the final release syntax is.
Conditional expressions are a nice way to shim something in place, on
an acute basis. Chronic use of them could lead to a full-on plate of
spaghetti, where you really wanted code.
They can be impenitrable. Whenever I'm dealing with them in C/C++, I
always line the ?, the :, and the ; characters vertically, which may
seem a bit excessive in terms of whitespace, but provides a nice
hieroglyph over on the right side of the screen, to make things
obvious.
Best,
Chris


Regards,
Bengt Richter
Oct 15 '05 #62
"Peter Hansen" <pe***@engcorp.com> wrote in message
news:4r******************************@powergate.ca ...
Dave Hansen wrote:
So lose the "if."

R = C then A else B


I think that part of the argument for the "A if C else B" syntax is that
"then" is not currently a reserved word.
Oct 16 '05 #63

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

26 posts views Thread by Ney André de Mello Zunino | last post: by
8 posts views Thread by Olov Johansson | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Geralt96 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.