[Info] PEP 308 accepted - new conditional expressions

[Terry Hancock]

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").

 

[Steven D'Aprano]

....
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

 

[phil hunt]

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!

 

[Terry Hancock]

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.

 

[Dave Hansen]

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).

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.

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,

Confusing how? Perform test, choose branch. Simple.

And it's not punctuation. It's an operator, just like + or & or ~. I
can understand how you might find the terseness confusing, though.

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).

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.

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.

Easy to read out loud, but complex to understand, with all the back
and forth scanning required.

No doubt, ANY choice of ternary operator for Python will be
criticized, and no doubt, ANY choice would nevertheless be
usable.

The whole idea of a ternary operator is somewhat complex.

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.

I guess I agree, thoug I would have preferred to see something like
r = c ?then: yes else: no

Consistency certainly does make it easier for me to remember.

I guess I disagree that it's consistent, at least with the way I see
python.

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.

I'm inexperienced enough to keep Beazley's book at my elbow when
writing my own code, though reading other's code is usually simpler.
Until things like __metaclass__ and @classmethod start showing up...

Regards,

-=Dave

 

[Sebastian Bassi]

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?

 

[Peter Hansen]

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

 

[George Sakkis]

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

 

[Eric Nieuwland]

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

 

[Antoon Pardon]

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.

 

[William Park]

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 <[email protected]>, 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/

 

[Chris Smith]

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

 

[Piet van Oostrum]

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.

 

[Duncan Booth]

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:

 

[Dave Hansen]

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

 

[Dave Hansen]

Paul Rubin <http://[email protected]> (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

 

[Roy Smith]

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.

 

[Peter Hansen]

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

 

[Piet van Oostrum]

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.

 

[Dave Hansen]

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