PEP308: Yet another syntax proposal

[Andrew Dalke]

Gustavo <sismex01 at hebmex.com>:
> My question is "why leave it half-done?"
>
> Why create a simple builtin function which doesn't do
> short circuiting and then resort to half-baked hacks
> when you do need it, when here's the chance to do it
> fully and have a sanctioned short-circuiting ternary
> operator, usable in all the cases the builtin would
> work, and then some.

Because short-circuiting isn't needed often (perhaps 1 in 5,000
lines of code) so it isn't useful to make yet another language
construct, with all the difficulties in parsing, interpretation, etc.,
when the vast majority of cases (perhaps 1 in 400 lines) can
be handled with a simple function that introduces no new
ideas to the language.

Note that if you accept that people who really want a ternary
if/else operator can sometimes live with

   cond and expr1 or expr2

then the only time an if/else operator is needed is for cases
when 'expr1' may be a false value.  And that is (according
to Tim Peter's analysis of the Python library code) even
more rare, with a frequency  I would estimate of about 1
use in 5 or rarer.

So should we introduce a new idiom to Python which
will only need to be used about once every 25,000 lines
of code, compared to an iff() builtin which will likely
be used about once every 400 lines and doesn't introduce
new fundamental ideas to the language?

Others would argue that a simple ternary if/else operator
is too limited and that it should support easy chaining;
an n-ary if/elif/else statement.  So they might argue that
your propose is still only "half-done."

                    Andrew
                    dalke at dalkescientific.com