Builtin function versus new syntax for PEP308 -- was Re: PEP308: Yet another syntax proposal
mchermside at ingdirect.com
Wed Feb 12 21:38:11 CET 2003
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
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" 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
More information about the Python-list