PEP308: Yet another syntax proposal

[Dave Brueck]

On Mon, 10 Feb 2003, Andrew Dalke wrote:

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

Perhaps, but maybe the fact that it is non-zero is what troubles me.
Python has short-circuiting logical operators and I use them in cases
where that matters _and_ when it doesn't, and I used C's conditional
operator in cases where short-circuiting mattered _and_ when it didn't, so
it's likely that I would intend to use it in Python the same way, but the
builtin-function way would be a half-way solution so I'd probably steer
clear from it altogether just to be safe.

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

Well, to me this feels like a trap because you are already fully aware of
when some people consider it useful and expressive, but in your opinion
it's still not worth it. My view obviously differs - even though, like
you, I've been programming in Python a long while, I still miss having it,
and I know that in some of those cases in which I had it they would
require short-circuiting behavior.

I do not disagree that in many uses of the conditional operator
short-circuiting would not matter. But, the cases in which it _does_
matter are some of the most useful to me. Furthermore, setting
short-circuiting aside, calling a separate function to make the binary
choice just _seems_ wrong - unPythonic and kinda like having to call if()
for normal if-statements - it just feels like a lot of extra work to
express a very simple thought, so much so that I'd probably handle it I do
now: grumble quietly about how I wish we had a conditional operator, and
then code it up in a way that doesn't quite capture what I mean but is
good enough.

I am in favor of the PEP because of *both* the short-circuiting *and* code
readability - it expresses *exactly* the thought I'm really trying to
convey in those instances that I use it, whereas

if c:
  z=5
else:
  z=6

doesn't quite do it, neither does:

z=6
if c:
  z=5

> This would provide useful real-world context for an if/else expression,

Having said the above:

The access-a-member-of-a-variable-if-not-None idiom seems to be the one I
encounter most often, e.g.

z = x.foo if x else -1

But even when I know a variable isn't None I also see similar variants
with data transmission/loading:

z = x.size() if x.loaded or '(Loading...)'

As mentioned elsewhere, this form is a way of expressing intended or
preferred or "normal" execution - it really expresses the "conditional"
nature - it's a conditional assignment in this case.

One other case I encounter less often deals with recalculation of cached
values, although depending on the specific context recalculation may occur
invisibly to the caller. In cases where it's not, then the check is
against some cache freshnes value. The same holds true for expiring
content:

resp = x.data if x.isFresh() else GetStaleResponse()

I am fully aware that any of these can be rewritten to another way -
that's not the issue. For me personally it's a matter of the most clear
and direct way to accomplish what I'm trying to do, other approaches feel
like the language is getting in the way.

In addition to the short-circuit-required type of uses, there are many
more in which it's just really clear and convenient for me to have such a
construct, but having to tread lightly and use it only when
short-circuiting is definitely not required would be enough of an
annoyance to not bother with a conditional function at all.

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

I believe too much has been concluded from these stats - I agree that it
would be great to have some real numbers but can we really infer what
people _would_ have done if a different construct were available,
especially when it is a matter of preference or experience?

Did you also include the use case I listed above (assign then check then
assign again - yeah, it's not short-circuiting, but is often a potential
use of conditional operators)?

Even though it's known to someone in C doesn't necessarily mean they would
give it an honest try, either - it's common around here to kindly
encourage people to "think Pythonically" so maybe people who didn't use it
in C were still thinking in their previous language.

-Dave