[Info] PEP 308 accepted - new conditional expressions

[Reinhold Birkenfeld]

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

[Fredrik Lundh]

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

</F>

[Richie Hindle]

[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

[Paul Rubin]

Richie Hindle <rj*@cyberscience.com> 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.

[Reinhold Birkenfeld]

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

[Rocco Moretti]

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

[Dave Benjamin]

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

[Reinhold Birkenfeld]

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

[Carl Banks]

Reinhold Birkenfeld wrote:

X if C else Y

Oh well. Just about any conditional is better than no conditional.

Carl Banks

[Erik Max Francis]

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

[Sam]

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

[Ron Adam]

Reinhold Birkenfeld wrote:

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)

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

[Jaime Wyant]

On 9/30/05, Sam <sa*@email-scan.com> 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

[Bengt Richter]

On Fri, 30 Sep 2005 20:25:35 +0200, Reinhold Birkenfeld <re************************@wolke7.net> 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

[Terry Reedy]

"Dave Benjamin" <ra***@lackingtalent.com> >

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

[Sam]

Jaime Wyant writes:

On 9/30/05, Sam <sa*@email-scan.com> 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-----

[Michele Simionato]

Terry Reedy ha scritto:

"Dave Benjamin" <ra***@lackingtalent.com> >

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.

<snip history of PEP 308>

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

[Reinhold Birkenfeld]

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

[Reinhold Birkenfeld]

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

[Reinhold Birkenfeld]

Sam wrote:

Jaime Wyant writes:

On 9/30/05, Sam <sa*@email-scan.com> 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

[Paul Rubin]

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.

[Leif K-Brooks]

Sam wrote:

And "foo if bar" is Perl-ish; yet, even Perl has the ? : operators.

What _isn't_ Perl-ish?

[John J. Lee]

"Michele Simionato" <mi***************@gmail.com> 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

[Sam]

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

[Ron Adam]

Reinhold Birkenfeld wrote:

Ron Adam

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

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

Cheers,
Ron

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

[Michael]

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

[Michael]

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.

[Volker Grabsch]

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]}}}

[Antoon Pardon]

Op 2005-09-30, Sam schreef <sa*@email-scan.com>:

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

[Christophe]

Michael a écrit :

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

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.

[Sion Arrowsmith]

Ron Adam <rr*@ronadam.com> wrote:

So ...

A if B else C + X * Y

Would 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

[Michael]

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

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.

[Terry Hancock]

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

[Robin Becker]

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

[Eric Nieuwland]

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

[Michael Ekstrand]

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

[Simon Brunning]

On 07/10/05, Eric Nieuwland <er************@xs4all.nl> 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/

[Fredrik Lundh]

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)

</F>

[Robin Becker]

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

[Terry Hancock]

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

[Steven D'Aprano]

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.

[phil hunt]

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!

--
Email: zen19725 at zen dot co dot uk

[Terry Hancock]

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?

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

[Dave Hansen]

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

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
--
Change is inevitable, progress is not.

[Sebastian Bassi]

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

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?

--
<a href="http://www.spreadfirefox.com/?q=affiliates&id=24672&t=1">La
web sin popups ni spyware: Usa Firefox en lugar de Internet
Explorer</a>

[Peter Hansen]

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

[George Sakkis]

"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
compatibility should not be top priorities in language design; fortunately for python, they're not.

George

[Eric Nieuwland]

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

[Antoon Pardon]

Op 2005-10-10, Terry Hancock schreef <ha*****@anansispaceworks.com>:

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?

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