PEP308: Yet another syntax proposal

[Andrew Dalke]

Dave Brueck:
> If the functionality can be exactly emulated with a function, then the
> utility of the new feature pretty much drops to zero (and my vote would
> swing from +1 to -1). The very fact that people _don't_ just write a
> little function (something far easier and less time consuming than, say,
> arguing in favor of this PEP) is at least some indication that it's judged
> to be worthwhile, even if how worthwhile can't be quanitifed with hard
> numbers, or even if it's not very worthwhile to you.

I don't write a function because there's no good name for it.
"Good name" defined as "something which isn't a dialect specific
to my code."

Were there a suggestion for an "ifelse()" builtin, then there would
be a good name.

> Also, the usefulness of short-circuiting has been shown in several
> realistic examples already,

Indeed,  and I have tried to point out that the frequency of that
use is, in actual code, quite low.

> To _me_ it is important because I have run into and continue to run into
> this same scenario and I find that, without a conditional operator, the
> language is getting in the way because the code I have to _write_ doesn't
> synch up very well with what I _mean_ (because what I mean is more
> accurately conveyed by a conditional expression).

Could you post, say, 5 examples where you would use this in
you code and provide broader context that would let us understand
the usefulness of a short-circuiting if/else expression over, say,
other existing Python idioms or a (still hypothetical) "ifelse()" function?

This would provide useful real-world context for an if/else expression,
to counter the numbers I found which suggest that a true
short-circuiting if/else expression is only needed roughly once
every 5,000 lines of Python code or so.

                    Andrew
                    dalke at dalkescientific.com