Builtin function versus new syntax for PEP308 -- was Re: PEP308: Yet another syntax proposal

[Chermside, Michael]

Gareth McCaughan writes:
> What's the actual *disadvantage* of short-circuiting? Is it only that
> if you have to short-circuit then you can't just write a new builtin
> and be done with it?

Tim Delaney responds:
> Control flow is not explicit. As I stated on another thread (damn - I
> was trying not to get involved in this too much ;) I have yet to read a
> ternary which *relies* on short-circuiting without needing to think hard
> about it.
> 
> Control flow should be explicit. Anything which participates in a
> short-circuiting expression should behave identically if the
> short-circuiting were not present. Short-circuiting should be an
> optimisation only.
> 
> i.e. You shouldn't have side-effects in a short-circuiting expression.


It's bad form to JUST have side-effects in a short-circuiting expression.
So, if I saw this (with ANY of the proposed syntaxes):

    if a>b: doActionForA() else: doActionForB()

I'd probably suggest a re-write. It's syntactically valid, but ought to
be written as an if STATEMENT not an if EXPRESSION. But this still leaves 
two other reasons why a conditional expression must short-circuit. First 
of all, the action may cause an ERROR. The canonical example is something 
like this:

    x = if a is not None: a.getData() else: getDefaultData()

Secondly, the evaluation may take a long time:

    x = if a.isInitialized(): a.getValue() else: a.computeValue()

Finally, I refer you to the PEP (http://www.python.org/peps/pep-0308.html),
where this is summarized nicely. That section ends with:

> Still, the point is moot since the BDFL opposes solutions
> which do not provide short-circuit behavior.

"Moot"[1] means "Subject to debate; arguable", and we can certainly fill
up c.l.py discussing whether short-circuiting is required. But let's
not, since it's not going to accomplish anything!

-- Michael Chermside

[1] http://dictionary.reference.com/search?q=moot