Guido van Rossum wrote:
[Guido]
Let me give you what you expect. If all the X if C else Y syntax
does is prevent that atrocity from ever being introduced, it would be
worth it. :)
[Steve]
Well, fine. However, it does allow atrocities like
func(f for f in lst if f -1 if f 0 else +1)
I did this for my favorite proposal, and ended up with the list shown
further down below.
I think they all looks great!
The fact that so few were found in whole of the standard library does
put the use case into question, though, no? Though I am sure more could
be found with a more
Guido:
Now you've pushed me over the edge. I've made up my mind
now, X if C else Y it will be. I hope to find time to
implement it in Python 2.5.
Steve Holden:
Not before time, either. If this ends the discussion then
I'll consider I've done everyone a favour. Sometimes no
decision is
On Wed, Sep 21, 2005, Nick Coghlan wrote:
Steven Bethard wrote:
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
FWIW, I find
[Aahz]
I'm also opposed to elif in conditional expressions -- let's keep this
a
simple Pythonic rewrite of C's ternary.
I'm +0 on requiring parentheses precisely because they're annoying.
I'm
still expecting simple boolean expressions to be the primary use case,
and my hunch is that overall
On 9/29/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
FWIW, I scanned the standard library for all the and/or pairings where a
conditional expression was applicable. This sampling can serve as a
reference for what typical uses would look like in real Python code as
created by a number of
On 9/29/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[a garbled list]
Stupid gmail broke the lines. Here it is again as an attachment.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
XifCelseY.py
Description: application/python
___
Guido van Rossum wrote:
I think they all looks great!
expression if expression?
looks like you've been doing too much Perl hacking lately ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
The only problem is that it's not easy to come up with a regex-based
way to transform
C and X or Y
into
X if C else Y
(my 2 cents)
I find this proposal very confusing. The order is not logical at all.
One usually expects to find the condition on one side, and the
alternatives
Guido After all there's nothing wrong with and/or.
Especially if it's correct. wink
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Raymond Hettinger wrote:
[Aahz]
I'm also opposed to elif in conditional expressions -- let's keep this
a
simple Pythonic rewrite of C's ternary.
I'm +0 on requiring parentheses precisely because they're annoying.
I'm
still expecting simple boolean expressions to be the primary use
Antoine Pitrou wrote:
This is especially true if the X in X if C else Y happens to be a
non-trivial expression - witness your example from unittest.py:
return doc.split(\n)[0].strip() if doc else None
... because then the condition (which is the most important part of the
statement)
Guido van Rossum wrote:
file = os.path.abspath(file) if file else '?'
...
These are all unreadable. In C a ? b : c is not used very often. A
quick check of the Python source found 476 occurences.
-1 to conditional expressions.
___
Python-Dev mailing
Guido van Rossum wrote:
On 9/29/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
FWIW, I scanned the standard library for all the and/or pairings where a
conditional expression was applicable. This sampling can serve as a
reference for what typical uses would look like in real Python code as
Antoine Pitrou wrote:
The only problem is that it's not easy to come up with a regex-based
way to transform
C and X or Y
into
X if C else Y
One way is to parse it manually to a list. This was just a test, but
more samples can be added friarly easy.
samples = [
# start, cond,
On 9/29/05, Steve Holden [EMAIL PROTECTED] wrote:
I would argue for mandatory parentheses around the expression, leaving
room later (probably after Guido is no longer around to be sick at the
site of it) for:
def f(condition):
return something if condition # no else!
return
Guido van Rossum wrote:
I did this for my favorite proposal, and ended up with the list shown
further down below.
I think they all looks great!
I'm sorry for my bad English
IMHO, if condition is nontrivial, then the syntax:
expr1 if some complex condition else expr2
can be more hard
[ongoing discussion of conditional expressions]
I waited until I had caught up on my reading before saying anything. Now I'll
express my opinion in a single posting then keep quiet unless I actually find I
have something novel to contribute (difficult in a topic that's been talked to
death 3 or 4
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
After all there's nothing wrong with and/or.
This is one reason 'no addition' got a relatively high rank in the vote.
Examples...
telnet~1.py:'DO' if cmd == DO else 'DONT',
versuscmd == DO
Guido van Rossum wrote:
On 9/29/05, Steve Holden [EMAIL PROTECTED] wrote:
I would argue for mandatory parentheses around the expression, leaving
room later (probably after Guido is no longer around to be sick at the
site of it) for:
def f(condition):
return something if condition # no
[Guido]
Let me give you what you expect. If all the X if C else Y syntax
does is prevent that atrocity from ever being introduced, it would be
worth it. :)
[Steve]
Well, fine. However, it does allow atrocities like
func(f for f in lst if f -1 if f 0 else +1)
No it doesn't! Inside an
Nick Coghlan wrote:
i.e., it's
like an or, only we're asking that the decision be made based on something
other than the truth value of the left hand operand.
Hmmm, then maybe it should be
a or c if b
or perhaps
a or, if b, c
:-)
--
Greg Ewing, Computer Science Dept,
New keyword is so expensive?
And why special case for 'then' is better than special case for 'take'?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Gustavo J. A. M. Carneiro wrote:
More realistic example:
def greet(person=None):
print Hello %s % (if person is None: World else: person)
Not as compact as C's ?:, but more readable and intuitive. It's just
like an if-else construct, but on a single line and () around to
On Saturday 2005-09-24 04:21, Terry Reedy wrote:
Never wrote a single line, and may have not read one (in DDJ? Byte?) for
15-20 years. How do *you* read such C? Cond 'Qmark' ?
I seldom have to read C code aloud, and the ?: operator is
rare-ish; but I would suggest reading a?b:c as a
Sorry for looking in every hole.
Just a suggestion.
A= condition and first or second
problem is in case when first in (None,0,[],).
May be invent new operator 'take'.
take - returns right operator when left evals to True and stops
computing condidtional expression.
Then we could write:
A =
Sokolov Yura wrote:
Sorry for looking in every hole.
Just a suggestion.
A= condition and first or second
problem is in case when first in (None,0,[],).
May be invent new operator 'take'.
take - returns right operator when left evals to True and stops
computing condidtional expression.
Terry Reedy wrote:
Now, can you honestly say that you would (naively) read
return foo if bar else baz
and be certain you knew what it meant?
I can honestly say that, given I knew I was reading Python
code, it would never have entered by head to read foo if
as meaning that foo was the
On 9/24/05, Terry Reedy [EMAIL PROTECTED] wrote:
Now, can you honestly say that you would (naively) read
return foo if bar else baz
and be certain you knew what it meant?
FWIW, yes, I can honestly say that I would be certain. Yes, you may be
able to *parse* it as (foo if) bar (esle baz) as
The reason I like a if b else c is because it has the
most natural word order. In English,
My dog is happy if he has a bone, else sad.
sounds much more natural than
My dog is, if he has a bone, happy, else sad.
Neither sounds very natural to me; conditional
expressions don't occur much
On 9/20/05, Nick Coghlan [EMAIL PROTECTED] wrote:
Basically, I'm +1 on the original PEP 308 form because it reads more naturally
(and more like LC's and GE's) to me in expression contexts, and +0 on the
if/then/elif/else form (because I would like a real conditional operator).
I agree that
Gareth McCaughan [EMAIL PROTECTED] wrote:
[seems to have gone off list with a portion of the discussion]
The reason I like a if b else c is because it has the
most natural word order. In English,
My dog is happy if he has a bone, else sad.
sounds much more natural than
My dog is,
Need I continue? Or is the dead still dead?
Since 'a if b else c' is not obviously dead, I will summarize my argument
against it thusly:
It is ambiguous to people because it is can be parsed (by people, who are
not automatons) as either '(a if) b (else c)' or 'a (if b) (else c)'. The
first
Jim Jewett [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
A nice summary, to which I will add just a little.
For a conditional expression, I think the choices are really down
to the following, which was already way too much freedom last
(http://www.python.org/peps/pep-0308.html)
Greg Ewing [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
Many people, perhaps most, including me, read
exp1 if exp2 else exp3 # as
cond if etrue else efalse # in direct analogy with
cond ? etrue : efalse # from C
I'd have thought only Forth
Terry Reedy wrote:
During the c.l.p debate, someone counted about 100 correct uses of 'a and b
or c' in the standard library. But one real misuse edged Guido toward
replacing it. So I think the replacement should be as clear as reasonably
possible and clearly an improvement.
But I think
On 9/23/05, Nick Coghlan [EMAIL PROTECTED] wrote:
But I think there's a difference in kind here - to *fix* Raymond's example
required a fundamental change to the structure of the line, none of which
looked as clean as the original. There is no way to get the and/or construct
to gracefully
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
snip discussion indicating that our brains work different on this issue
I am reminded of how some people seem to react to fingernails on a
blackboard, while the screech is just another noise to me, except that I am
in the
Andrew Koenig [EMAIL PROTECTED] wrote:
My problem with this syntax is that it can be hard to read:
return if self.arg is None then default else self.arg
looks worryingly like
return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
to me.
Interesting. What about
Jason Orendorff wrote:
Honestly, I think I would prefer this syntax. Examples from real
code, before and after:
lines = [line for line in pr.block.body
if line.logical_line.strip() != '']
lines = [for line in pr.block.body:
if
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
FWLIW, this was my (strong) preference back at the time of the
original discussion.
--
g
Guido van Rossum [EMAIL PROTECTED] writes:
Given the later addition of generator expressions with mandatory
parentheses , the mandatory-parentheses version of a conditional expression
looks less strange to me than it did then ;-). So I could happily use it
even though I may still lean toward
On Wed, 2005-09-21 at 11:10, Michael Hudson wrote:
My problem with this syntax is that it can be hard to read:
return if self.arg is None then default else self.arg
looks worryingly like
return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
to me.
I think that requriing parens
Greg Ewing wrote:
Guido van Rossum wrote:
I think if we go with (if ... then ... else ...) or (if ...:
... else: ...) we'll have to support elif as well:
(if ... then ... elif ... then ... else ...)
or
(if ...: ... elif ...: ... else: ...)
One nice thing about x if b else y is that it
Nick Coghlan wrote:
Greg Ewing wrote:
One nice thing about x if b else y is that it
chains without needing any more keywords:
x if b else y if c else z
But if you require parens, it's not so nice:
(x if b else (y if c else z))
If Guido chose this form, I would expect the chaining to
Michael Hudson wrote:
Guido van Rossum [EMAIL PROTECTED] writes:
Given the later addition of generator expressions with mandatory
parentheses , the mandatory-parentheses version of a conditional expression
looks less strange to me than it did then ;-). So I could happily use it
even though
Adam wrote:
So looking at a few alternatives ...
[snip]
(e ? (e1 ? a1 : b1) : (e2 ? a2 : b2))
[snip]
(if e, (if e1, a1 else b1) else (if e2, a2 else b2))
[snip]
(if e then (if e1 then a1 else b1) else (if e2 then a2 else b2))
[snip
(e selects (e1 selects a1 else b1) else (e2 selects a2
On 9/21/05, Steven Bethard [EMAIL PROTECTED] wrote:
Please no more syntax proposals! There were enough in the PEP. It
looks like most people support a conditional expression of some sort.
We need to leave the syntax to Guido. We've already proved that like
the decorators discussions, we
I think I'd prefer (if expr then expr else expre) i.e. no
colons.
My problem with this syntax is that it can be hard to read:
return if self.arg is None then default else self.arg
looks worryingly like
return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
That can already be
BJörn Lindqvist [EMAIL PROTECTED] writes:
My problem with this syntax is that it can be hard to read:
return if self.arg is None then default else self.arg
looks worryingly like
return NAME NAME.NAME NAME NAME NAME NAME NAME NAME.NAME
That can already be written in Python:
No it can't!
Guido:
When you invited resumed discussion, did you intend to proceed from where
the revised PEP left off (with a few variations on the table), or to start
over from point zero (with potentially anything and everything on the
table). In particular, do we need to rehash the reasons for
I think a recap of past arguments is useful. Me-too votes are not. i
will read everything and pick a syntax and that's it. We can do it in
Python 2.5.
On 9/21/05, Terry Reedy [EMAIL PROTECTED] wrote:
Guido:
When you invited resumed discussion, did you intend to proceed from where
the revised
Ron Adam wrote:
( e selects (e1 selects a1, b1),
(e2 selects a2, b2),
(e3 selects a3, b3) )
I think you've just reinvented the case statement, which
disagrees with if over the order of true and false clauses.
For a conditional expression, I think the
Steven Bethard wrote:
Please no more syntax proposals! There were enough in the PEP. It
looks like most people support a conditional expression of some sort.
We need to leave the syntax to Guido. We've already proved that like
the decorators discussions, we can't as a community agree on a
Jim Jewett wrote:
a very nice summary
(3) What order should the clauses appear?
(if test then True else False)
(if test1 then Val1 elif test2 Val2 elif test3 Val3 else Val4)
+ Natural Order
- do we need then?
(True if normal else False)
(Val1 if test1 else
Ron Adam wrote:
(a if e then b)
((a1 if e1 then b1) if e then b)
(a if e then (a2 if e2 then b2))
((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all
those, don't you?
--
Greg Ewing, Computer Science Dept,
Greg Ewing wrote:
Ron Adam wrote:
(a if e then b)
((a1 if e1 then b1) if e then b)
(a if e then (a2 if e2 then b2))
((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all
those, don't you?
Yes of course, thanks for correcting.
Gary Herron wrote:
And in fact, one read and understands your return statement just like an
English sentence -- word by word from beginning to end. This seems an
argument FOR the syntax not against.Moreover, if one uses the
proposed parenthesized syntax, even the slightly odd word
On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] writes:
On 9/19/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
I propose that in Py3.0, the and and or operators be simplified to
always return a Boolean value instead of returning the last evaluated
Guido van Rossum wrote:
Given this realization, I'm now -1 on Raymond's idea, and +1 on adding
a conditional expression. I believe (y if x else z) was my favorite
last time, wasn't it? I've changed the subject accordingly.
As the PEP states, I'm not sure if changing the customary order of
On Tue, Sep 20, 2005 at 09:04:53AM -0700, Guido van Rossum wrote:
On 9/20/05, Michael Hudson [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] writes:
On 9/19/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
I propose that in Py3.0, the and and or operators be simplified to
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
In fact, I think Raymond's example is more properly considered an
argument for adding a conditional expression than for removing the
current behavior of the and/or shortcut operators; had we had a
conditional
On 9/20/05, Terry Reedy [EMAIL PROTECTED] wrote:
Guido van Rossum [EMAIL PROTECTED] wrote in message
and +1 on adding a conditional expression. I believe (y if x else z)
was my favorite last time, wasn't it?
No. That was your original proposal, which you later rejected.
Thanks for
At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
+1, despite the fact that we seem on a slippery slope
On 9/20/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 12:17 PM 9/20/2005 -0700, Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
FWIW, I find this quite intuitive. It follows the same pattern as LCs
and GEs
(Adding python-dev back to the CC list)
On 9/20/05, Jason Orendorff [EMAIL PROTECTED] wrote:
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.
+1
Some visual aids:
On Tue, 2005-09-20 at 17:40, Guido van Rossum wrote:
Ouch. You're bringing up another valid issue: whether to support
elif. I think if we go with (if ... then ... else ...) or (if ...:
... else: ...) we'll have to support elif as well:
I'm not so sure. Once you start writing such a
Guido van Rossum [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On 9/20/05, Terry Reedy [EMAIL PROTECTED] wrote:
Given the later addition of generator expressions with mandatory
parentheses , the mandatory-parentheses version of a conditional
expression
looks less strange to me
On 9/20/05, Guido wrote:
On 9/20/05, Jason Orendorff [EMAIL PROTECTED] wrote:
return (if q: q.popleft() else: None)
return (if q then q.popleft() else None)
return q ? q.popleft() : None
Hmmm. Score one for ?:.
Why? Just because it's shorter?
Just a gut response to the
Steven Bethard wrote:
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no
colons. None of the other expression forms (list comprehensions and
generator expressions) involving statement keywords use colons.
FWIW, I find this quite intuitive. It follows the
Guido van Rossum wrote:
I think I'd prefer (if expr then expr else expre) i.e. no colons.
None of the other expression forms (list comprehensions and generator
expressions) involving statement keywords use colons.
While I like the looks of the form without colons better, I can't quite
follow
Barry Warsaw wrote:
I'm not so sure. Once you start writing such a complicated thing, I think
readability will favor just breaking the code out into traditional
if-blocks. I'd be happy enough with just a binary condition.
Nothing prevents you from spreading the code over multiple lines,
On Tue, 2005-09-20 at 18:21, Thomas Lotze wrote:
Nothing prevents you from spreading the code over multiple lines, like so:
x = (if a then b
elif c then d
else e)
or even
x = (if a then
b
elif c then
d
else
e
)
especially as
Guido van Rossum:
I think I'd prefer (if expr then expr else expre)
In isolation, (if .. then ... else) is an improvement, but I'm
not sure it should be viewed in isolation.
At one point, you wanted to strengthen the distinction
between statements and expressions. Is that still true?
x =
Barry Warsaw wrote:
x = (if a then
b
elif c then
d
else
e
)
[...]
I guess that's my point. To me, your latter is actually worse than
if a:
x = b
elif c:
x = d
else:
x = e
Can't see a difference as far as readability is
On Wed, 21 Sep 2005, Thomas Lotze wrote:
Barry Warsaw wrote:
x = (if a then
b
elif c then
d
else
e
)
[...]
I guess that's my point. To me, your latter is actually worse than
if a:
x = b
elif c:
x = d
else:
x
On Tue, 20 Sep 2005, John J Lee wrote:
[...]
With the former, we have a more C-style syntax where meaning is determined
purely by delimeters rather than by whitespace. Instead of braces '{' and
'}', we have 'then' and 'elif'/'else'. That's a real difference.
[...]
Um, not clear, sorry: the
John J Lee [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
The stricter form where you don't allow 'elif' will get used in more
restricted circumstances, so gives less encouragement for widespread
abuse
of conditional expressions by people who don't like whitespace-based
syntax.
Terry Reedy wrote:
The original version of this PEP proposed the following syntax:
expression1 if condition else expression2
The out-of-order arrangement was found to be too uncomfortable
for many of participants in the discussion; especially when
expression1 is long,
Guido van Rossum wrote:
I think if we go with (if ... then ... else ...) or (if ...:
... else: ...) we'll have to support elif as well:
(if ... then ... elif ... then ... else ...)
or
(if ...: ... elif ...: ... else: ...)
One nice thing about x if b else y is that it
chains without
81 matches
Mail list logo
