Another conditional expression candidate (PEP 308)
Evan
The parentheses and 'else:' clause are mandatory. Leave them off and
you get a SyntaxError.
The conditions and expressions appear in "natural" order -- the same
order as in an 'if' statement, and the order in which they will be
evaluated (short-circuiting aside).
No new keyword is introduced. The grammar is unambiguous. The syntax
is utterly familiar and easy to remember, since it is "just like" the
'if' statement, but in an expression context.
This has been proposed in the past (see
http://groups.google.com/groups?threadm=mailman.1000046772.19777.python-list%40python.org),
and I can't find any specific objections to it, other than someone
uncomfortable with the idea of mandatory parentheses.
Cheers,
Evan @ 4-am
Roy Smith
> x = (if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
>
> The parentheses and 'else:' clause are mandatory. Leave them off and
> you get a SyntaxError.
Why is the else: manditory? Why not have it return None if none of the
conditions are true? It seems natural, and makes the syntax even more
like the current if statement. Other than that, I think I like it. I
certainly like it better than any of the other alternatives I've seen.
The next step (I'm being deliberately subversive here) is to say that
enclosing any statement in ()'s turns it into an expression whose value
is the last thing evaluated in the statement. That would let you do
things like:
while (x = foo()):
Erik Max Francis
> x = (if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
>
> The parentheses and 'else:' clause are mandatory.
I suggested the same in these recent PEP threads as well.
> This has been proposed in the past ... and I can't find any specific
> objections to it, other than someone
> uncomfortable with the idea of mandatory parentheses.
In the recent threads, the main objection that seemed to be raised was
that of a general trend of expressionizing statements. Others also
expressed some displeasure at the required parentheses. I don't know if
that's really all that bad; the required brackets in list
comprehensions, for instance, are damn helpful in setting them off as in
"something special happens in here."
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ He who knows how to be poor knows everything.
\__/ Jules Michelet
Rules for Buh / http://www.alcyone.com/max/projects/cards/buh.html
The official rules to the betting card game, Buh.
Erik Max Francis
> Why is the else: manditory? Why not have it return None if none of
> the
> conditions are true? It seems natural, and makes the syntax even more
> like the current if statement.
Explicit is better than implicit. After all, is "else: None" (or "else
None" in the original PEP) _really_ too much to type?
Roy Smith
>> Why is the else: manditory? Why not have it return None if none of
>> the
>> conditions are true? It seems natural, and makes the syntax even more
>> like the current if statement.
Erik Max Francis <m...@alcyone.com> wrote:
> Explicit is better than implicit. After all, is "else: None" (or "else
> None" in the original PEP) _really_ too much to type?
If "else: pass" isn't required in the statement, why should "else: None"
be required in the expression?
Erik Max Francis
> If "else: pass" isn't required in the statement, why should "else:
> None"
> be required in the expression?
Because in the statement form, the default "else" portion is to do
nothing whatsoever. In the expression, it can't do nothing; it has to
do something. I agree that if you _do_ want to make the "else" portion
optional, None is the logical choice, but I don't see the pressing need
for it to be optional in the first place.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Patiently, I'm still / Holding out until
\__/ Sandra St. Victor
Church / http://www.alcyone.com/pyos/church/
A lambda calculus explorer in Python.
Andrew Koenig
>> x = (if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
>> The parentheses and 'else:' clause are mandatory.
Erik> I suggested the same in these recent PEP threads as well.
I don't see any reason for the parens to be mandatory.
In particular, I don't see any reason why I should not be
able to write
foo(if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
or, for that matter,
fact = lambda n: if n == 0: 1 else: n*fact(n-1)
I don't think there are any ambiguities here.
--
Andrew Koenig, a...@research.att.com, http://www.research.att.com/info/ark
Andrew Koenig
Roy> "else: None" be required in the expression?
Because "pass" is obviously the only sensible default behavior for
statements, but None is not obviously the only sensible default value
for conditional expressions.
Terry Reedy
"Erik Max Francis" <m...@alcyone.com> wrote in message
news:3E46EADE...@alcyone.com...
> Evan wrote:
>
> > x = (if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
> >
> > The parentheses and 'else:' clause are mandatory.
>
> I suggested the same in these recent PEP threads as well.
I am pretty sure I prefer this to the PEP proposal, which seems
backwards to me.
TJR
]
Roy Smith
> nothing whatsoever. In the expression, it can't do nothing; it has to
> do something. I agree that if you _do_ want to make the "else" portion
> optional, None is the logical choice, but I don't see the pressing need
> for it to be optional in the first place.
The only pressing need is to try and keep things as uniform and
orthogonal as possible. The "if" statement doesn't need an else clause,
and does nothing if the condition is not met. A fuction doesn't need to
end in a "return" statement, and returns None if it falls off the end.
Given those, it just seems logical that an ternary expression shouldn't
need an else clause, and should return None if there isn't any.
Granted, I suspect in almost every case where you'd want to return None
as a default, putting in the explicit "else None" would be stylisticly
better, it doesn't seem necessary to require it.
Erik Max Francis
> I don't see any reason for the parens to be mandatory.
> In particular, I don't see any reason why I should not be
> able to write
>
> foo(if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
>
> or, for that matter,
>
> fact = lambda n: if n == 0: 1 else: n*fact(n-1)
>
> I don't think there are any ambiguities here.
The only issue I see here parser wise is that if someone's wacky enough
to use the expression as a standalone statement (as mentioned in the PEP
itself, albeit with the `if C then x else y' form, not the `if C: x
else: y' form we're talking about here, it'd take a bit of lookahead to
realize that what you've got is an expression, not a statement.
Requiring parentheses would eliminate that case faster without the
lookahead, since you damn sure can't have an if statement following an
open parenthesis. As I mentioned, I don't know enough about the parser
internals to know whether that would really be a significant benefit.
The more I look at it, the more I like it.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
Paul Rubin
> Roy> If "else: pass" isn't required in the statement, why should
> Roy> "else: None" be required in the expression?
>
> Because "pass" is obviously the only sensible default behavior for
> statements, but None is not obviously the only sensible default value
> for conditional expressions.
Again looking at the Lisp precedent, (cond (x y)) gives nil if x is
false, and that seems to have worked out. So I'm ok with making the
else optional. I'm also ok with making it mandatory.
Alan Daniels
>x = (if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
>
>The parentheses and 'else:' clause are mandatory. Leave them off and
>you get a SyntaxError.
Am I missing something? The whole point of a ternary operator is to
save you extra typing. This just seems to take everything you'd
typically write and squish it into one line.
Also, I think this would also be VERY confusing to new users.
This would be legal syntax:
result = if cond: x else: y
But this...
result = if cond:
x
else:
y
...would be illegal (it certainly is *now*, anyway). So to implement
this would require changing the fact that "if" blocks are not
expressions. Do I understand this correctly? Thanks.
Paul Rubin
> Am I missing something? The whole point of a ternary operator is to
> save you extra typing.
I don't think that's the whole point.
> This just seems to take everything you'd typically write and squish it
> into one line.
Yes, so you can pass it as a function arg or whatever.
> Also, I think this would also be VERY confusing to new users.
When you're done explaining metaclasses to new users, tell me if you
still think conditional expressions will confuse them too much.
> This would be legal syntax:
>
> result = if cond: x else: y
>
> But this...
>
> result = if cond:
> x
> else:
> y
>
> ...would be illegal (it certainly is *now*, anyway). So to implement
> this would require changing the fact that "if" blocks are not
> expressions. Do I understand this correctly? Thanks.
You might have to use backslashes to escape the ends of the lines,
just like you sometimes have to do in long statements now.
Andrew Koenig
Alan> This would be legal syntax:
Alan> result = if cond: x else: y
Alan> But this...
Alan> result = if cond:
Alan> x
Alan> else:
Alan> y
Alan> ...would be illegal (it certainly is *now*, anyway). So to implement
Alan> this would require changing the fact that "if" blocks are not
Alan> expressions. Do I understand this correctly? Thanks.
Why is this any more confusing than the fact that
result = x +
y +
z
is illegal?
Samuele Pedroni
"Andrew Koenig" <a...@research.att.com> ha scritto nel messaggio
news:yu99isvs...@europa.research.att.com...
> Alan> Also, I think this would also be VERY confusing to new users.
> Alan> This would be legal syntax:
>
> Alan> result = if cond: x else: y
>
> Alan> But this...
>
> Alan> result = if cond:
> Alan> x
> Alan> else:
> Alan> y
>
> Alan> ...would be illegal (it certainly is *now*, anyway). So to implement
> Alan> this would require changing the fact that "if" blocks are not
> Alan> expressions. Do I understand this correctly? Thanks.
>
> Why is this any more confusing than the fact that
>
> result = x +
> y +
> z
>
> is illegal?
x+
y+
z
is not a valid statement.
Alan Daniels
<http://phr...@NOSPAM.invalid> wrote:
>When you're done explaining metaclasses to new users, tell me if you
>still think conditional expressions will confuse them too much.
I don't ever plan on explaing metaclasses to new users. :-)
Andrew Koenig
>> result = x +
>> y +
>> z
>> is illegal?
Samuele> x+
Samuele> y+
Samuele> z
Samuele> is not a valid statement.
And I am not proposing that
result = if cond:
x
else:
y
should be a valid statement either.
So where is the problem?
Samuele Pedroni
> >> Why is this any more confusing than the fact that
>
> >> result = x +
> >> y +
> >> z
>
> >> is illegal?
>
> Samuele> x+
> Samuele> y+
> Samuele> z
>
> Samuele> is not a valid statement.
>
> And I am not proposing that
>
> result = if cond:
> x
> else:
> y
>
> should be a valid statement either.
>
> So where is the problem?
I have only explained the more.
Anders J. Munch
news:roy-0250BA.1...@reader1.panix.com...
> Evan <ev...@4-am.com> wrote:
>
> > x = (if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
> >
> > The parentheses and 'else:' clause are mandatory. Leave them off and
> > you get a SyntaxError.
>
> Why is the else: manditory? Why not have it return None if none of the
> conditions are true?
Let's take one thing at a time. You can always propose this in a later PEP.
- Anders
Evan
> Am I missing something? The whole point of a ternary operator is to
> save you extra typing.
No. If that were the whole point then the idea would have died long
ago. It's about clarity of expression.
> Also, I think this would also be VERY confusing to new users.
> This would be legal syntax:
>
> result = if cond: x else: y
>
> But this...
>
> result = if cond:
> x
> else:
> y
>
> ...would be illegal
This is part of why I suggested mandatory parens. Then both of these
are legal, and there is no confusion:
result = (if cond: x else: y)
result = (if cond:
x
else:
y)
Cheers,
Evan @ 4-am
Evan
> I don't see any reason for the parens to be mandatory.
It eliminates the Corner Case, precedence issues, and Alan Daniels
objection elsewhere in this thread.
> In particular, I don't see any reason why I should not be
> able to write
>
> foo(if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
Now add an operator to the right end of the expression. Sure, it is
possible to set up precedence so that it usually "does the right thing",
but an inexperienced programmer, or one who simply prefers not to use
conditional expressions in their own code, will have to stop and think
when they read in someone else's code:
foo(if a > 0: 'positive' elif a == 0: 'zero' else: 'negative', 1)
Is that a tuple or a pair of arguments? On the other hand,
foo((if a > 0: 'positive' elif a == 0: 'zero' else: 'negative'), 1)
See? Also, parse this for me (assuming that those who also want else:
to be optional win):
x = if c1: e1 elif c2: if c3: e3 else: e4
Now parse this:
x = (if c1: e1 elif c2: (if c3: e3) else: e4)
My point is that if Guido is going to agree to add this controversial
new feature to Python, the result should be absolutely
no-thought-required readable and consistent. Nothing optional, apart
from the inherent n-way optionality of the elif: clauses. No precedence
questions. No Corner Case. Dead simple.
Cheers,
Evan @ 4-am
Evan
> Why is the else: manditory? Why not have it return None if none of the
> conditions are true?
Firstly, because while it is clear to *you* that "if x: 1" will be None
if 'x' is false, it isn't necessarily clear to someone who is new to
Python or who never uses conditional expressions. Your code is now less
readable.
Secondly, parse this for me (assuming that those who object to mandatory
parentheses win):
x = if c1: e1 elif c2: if c3: e3 else: e4
Now try:
x = if c1: e1 elif c2: if c3: e3 else: None else: e4
You wouldn't write it without clarifying parens? Someone would.
Anders J. Munch
> I don't see any reason for the parens to be mandatory.
> In particular, I don't see any reason why I should not be
> able to write
>
> foo(if a > 0: 'positive' elif a == 0: 'zero' else: 'negative')
Mandatory parentheses doesn't mean there has to be a grammar
production that goes "if_expr ::= '(' 'if' ... ')'".
This particular example is enclosed in parens. And is therefore
accepted by the grammar changes proposed in
<news:EEb1a.63692$Hl6.7...@news010.worldonline.dk>.
- Anders
Greg Brunet
news:RnO1a.12380$yn1.9...@twister.austin.rr.com...
> Andrew Koenig wrote:
> > I don't see any reason for the parens to be mandatory.
>
> It eliminates the Corner Case, precedence issues, and Alan Daniels
> objection elsewhere in this thread.
>
.
.
> See? Also, parse this for me (assuming that those who also want else:
> to be optional win):
>
> x = if c1: e1 elif c2: if c3: e3 else: e4
>
> Now parse this:
>
> x = (if c1: e1 elif c2: (if c3: e3) else: e4)
>
> My point is that if Guido is going to agree to add this controversial
> new feature to Python, the result should be absolutely
> no-thought-required readable and consistent. Nothing optional, apart
> from the inherent n-way optionality of the elif: clauses. No
precedence
> questions. No Corner Case. Dead simple.
As a Python newbie, I like this candidate the best of all those
presented so far. I can figure out what it's doing the very first time
without having to have it explained to me, and as you show in your
examples, the parenthesis continue to make the precedence very clear.
Now one thing I'm not sure of from your last example (above), is that I
thought you said that the "else:" clause was mandatory, but it's not
present for the (if c3: e3) expression. Also, from your examples, is it
correct to assume that the "elif:" clause is NOT required?
--
Greg
Andrew Koenig
Anders> accepted by the grammar changes proposed in
Anders> <news:EEb1a.63692$Hl6.7...@news010.worldonline.dk>.
I'll follow up to that message.
Erik Max Francis
> My point is that if Guido is going to agree to add this controversial
> new feature to Python, the result should be absolutely
> no-thought-required readable and consistent. Nothing optional, apart
> from the inherent n-way optionality of the elif: clauses. No
> precedence
> questions. No Corner Case. Dead simple.
Bravo! [throws roses on stage]
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Ride / Ride this wave of mine
\__/ Res
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Erik Max Francis
> Also, from your examples, is it
> correct to assume that the "elif:" clause is NOT required?
Absolutely. The basic form would be
if C: x else: y
Chaining two together would result in
if C: x else: if D: y else: z
which has an obvious contraction to
if C: x elif: D: y else: z
All consistent with what you already know, newbie or not, about the
semantics of the if statement.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
Erik Max Francis
> This is part of why I suggested mandatory parens. Then both of these
> are legal, and there is no confusion:
>
> result = (if cond: x else: y)
>
> result = (if cond:
> x
> else:
> y)
Why make them mandatory? If you want to go multiline, you can just add
the parentheses yourself and get them for free. Making them mandatory
seems heavy handed for getting a certain indentation flow you _might_
want to use.
James J. Besemer
Erik Max Francis wrote:
> Why make them mandatory? If you want to go multiline, you can just add
> the parentheses yourself and get them for free. Making them mandatory
> seems heavy handed for getting a certain indentation flow you _might_
> want to use.
>
Yes!
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:j...@cascade-sys.com
http://cascade-sys.com
Anders J. Munch
>
> > This is part of why I suggested mandatory parens. Then both of these
> > are legal, and there is no confusion:
> >
> > result = (if cond: x else: y)
> >
> > result = (if cond:
> > x
> > else:
> > y)
>
> Why make them mandatory? If you want to go multiline, you can just add
> the parentheses yourself and get them for free. Making them mandatory
> seems heavy handed for getting a certain indentation flow you _might_
> want to use.
The BDFL shot down the straight, parentheses not required version, in
the pep. Looks too much like a statement. Perhaps requiring
the parentheses that I would have used anyway will mend that.
just-trying-to-force-my-preferred-style-down-everybody's-throat-ly
y'rs, Anders
Erik Max Francis
> The BDFL shot down the straight, parentheses not required version, in
> the pep. Looks too much like a statement. Perhaps requiring
> the parentheses that I would have used anyway will mend that.
Does it? The example shows the syntax with parentheses, but doesn't
really make a specific point about that. He's no fool, so I guess that
does suggest the parentheses will be required, but it's not entirely
clear. (Correct me if I'm wrong; I see no mention of the parentheses
being required.)
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ I always entertain great hopes.
\__/ Robert Frost
REALpolitik / http://www.realpolitik.com/
Get your own customized newsfeed online in realtime ... for free!
Anders J. Munch
>
> > The BDFL shot down the straight, parentheses not required version, in
> > the pep. Looks too much like a statement. Perhaps requiring
> > the parentheses that I would have used anyway will mend that.
>
> Does it? The example shows the syntax with parentheses, but doesn't
> really make a specific point about that.
He did in the first version of the PEP.
He's-allowed-to-change-his-mind-of-course-ly y'rs, Anders
Aahz
>>
>> The BDFL shot down the straight, parentheses not required version, in
>> the pep. Looks too much like a statement. Perhaps requiring
>> the parentheses that I would have used anyway will mend that.
>
>Does it? The example shows the syntax with parentheses, but doesn't
>really make a specific point about that. He's no fool, so I guess that
>does suggest the parentheses will be required, but it's not entirely
>clear. (Correct me if I'm wrong; I see no mention of the parentheses
>being required.)
I've sent e-mail to Raymond Hettinger requesting clarification.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Register for PyCon now! http://www.python.org/pycon/reg.html
Erik Max Francis
> I've sent e-mail to Raymond Hettinger requesting clarification.
From an email conversation I was cc'd on involving Guido, I believe the
parentheses _were_ intended to be required. Which I personally have no
strong objection to, I just don't think their necessity is necessary
:-).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Being in love for real / It ain't like a movie screen
\__/ India Arie
Bosskey.net: Aliens vs. Predator 2 / http://www.bosskey.net/avp2/
A personal guide to Aliens vs. Predator 2.
Aahz
>>
>> I've sent e-mail to Raymond Hettinger requesting clarification.
>
>From an email conversation I was cc'd on involving Guido, I believe the
>parentheses _were_ intended to be required. Which I personally have no
>strong objection to, I just don't think their necessity is necessary
>:-).
This has now been clarified; parentheses *are* required. I've sent
e-mail correcting the typo, though. ;-)
Bob berkey
> Secondly, parse this for me (assuming that those who object to mandatory
> parentheses win):
>
> x = if c1: e1 elif c2: if c3: e3 else: e4
>
What does this mean?
x = (if c1: e1 elif c2: (if c3: e3 else: e4))
or
x = (if c1: e1 elif c2: (if c3: e3) else: e4)
Elsewhere in the thread you implied the latter. I just wanted
to reinforce your point, and say this complex enough without having
to decipher which if/elif does that else belong to.
my 2cents
Bob
Andrew Koenig
Bob> What does this mean?
Bob> x = (if c1: e1 elif c2: (if c3: e3 else: e4))
Bob> or
Bob> x = (if c1: e1 elif c2: (if c3: e3) else: e4)
I think they should both be invalid.
Bob> Elsewhere in the thread you implied the latter. I just wanted
Bob> to reinforce your point, and say this complex enough without having
Bob> to decipher which if/elif does that else belong to.
I don't see the problem, as long as you follow the following rules:
1) Replace each "elif" by "else if"
2) After (1), each "if" must have exactly one "else" that
corresponds to it.
By implication, the number of "else" keywords must always be equal
to the number of "if" keywords, a state of affairs that does not
apply to either of the examples above.