For review: PEP 308 - If-then-else expression

[Ryan]

A terinary ... , in Python.
If anyone has a real __NEED__ for this, they can code it in as a
function for their own use.
Something small involving eval probably.  Just name it select or
choice.
I don't have any impetius to write in an example, but if pressed I
will :D
  It doesn't deserve anything being added into the VM (parser really,
I'm guessing, but I haven't looked at the internals to check how it is
implemented, it just works)
One of the best things about Python is the readability, people that
only know higher languages don't have a real need to remember some
obscure corner case thing when they are refactoring  code, just
because reading an if-else-then is easy for someone with a C
background.  Even worse, all the C programmers may start using it
constantly and begin obfuscating their code for the non-C people (and
the people that don't want to parse out nested terinary operations).

In short the gain; (a minor conviniance, and a smidge more code on the
screen),
does __NOT__ mitigate the loss; (time Guido code be writing productive
code instead of fighting with the parser, possible bugs introduced by
said fighting, and possible code obfuscation).

There is no real reason for something this inane and minor being add,
also, as a minor note:
This would affect all of the different Python ports for compatability
(such as it is) on Jython, Pippy, Stackless, Vyper, ObjPy, etc...

If anyone has an enumerated list of reasons that address all of these
issues I would be glad to hear them, but I don't see any reasonable
gain from this.

srart____remove_this_underlined_part_ at operamail___.com*

Guido van Rossum <guido at python.org> wrote in message news:<mailman.1044638179.4983.python-list at python.org>...
> Given that if-then-else expressions keep being requested, I hereby put
> forward a proposal.  I am neutral on acceptance of the proposal; I'd

> Introduction
> 
>     Requests for an if-then-else ("ternary") expression keep coming up
>     on comp.lang.python.  This PEP contains a concrete proposal of a
>     fairly Pythonic syntax.  This is the community's one chance: if
>     this PEP is approved with a clear majority, it will be implemented
>     in Python 2.4.  If not, the PEP will be augmented with a summary
>     of the reasons for rejection and the subject better not come up
>     again.  While I am the author of this PEP, I am neither in favor
>     nor against this proposal; it is up to the community to decide.
>     If the community can't decide, I'll reject the PEP.
>