Builtin function versus new syntax for PEP308 -- was Re: PEP308: Yet another syntax proposal
Gareth.McCaughan at pobox.com
Wed Feb 12 00:35:17 CET 2003
> You're missing the point. How frequently does this occur such that
> getting all our knickers in a twist is worth it? So far, most of the
> examples pushing a conditional expression have *NOT* required
> short-circut behavior. For the cases where side-effects restrict the
> use of a conditional expression, I think perhaps requiring the use of an
> if statement is the most appropriate way to handle it.
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?
It seems to me that there is *no* advantage to a builtin function
over a new syntax (provided the syntax is chosen well), other than
the implementation effort.
The arguments against (any given version of) the proposal are
1 It enlarges the language and therefore makes it harder to learn.
2 It can be abused to produce horrible code.
3 It's ugly.
4 It's confusing even when not abused.
The arguments for it are
5 It reduces code duplication.
6 It leads to more concise code.
7 If we don't have it, people will use horrible surrogates.
I claim that arguments 1..4 apply just as much to a new builtin
as they do to a new syntax. For concreteness, let's compare
"ifelse(C,x,y)" to "if C: x else: y".
#1: ease of learning.
Learning about a new function takes time, just as learning about
a new bit of syntax does. Does anyone have any evidence that
"ifelse(C,x,y)" would be easier to master than "if C: x else: y"?
I certainly haven't seen any. For what it's worth, my baseless
guess is that beginners are more likely to say "huh?" to the
function than to the if-expression. (I've spent quite a lot of
time teaching programming to 12-15-year-olds using Python, which
may or may not be reason to trust my intuition on this.)
Like it or not, Python consists of the core syntax *plus*
the builtin types and their semantics *plus* the standard
library. Adding a new builtin function makes Python more
complicated just as much as adding a new bit of syntax does.
And, at least for the "if C: x else: y" spelling of the
conditional expression, the new syntax can be explained as
quickly as "if both arms of an if are expressions, you can
write it on a single line and use the whole thing as an expression".
#2: possibility of abuse.
Well, of course, *anything* can be abused; we all know that.
The question is: given any particular level of malignity or
thoughtlessness, how horrible is the resulting abuse likely
to be? :-)
Well, here are a couple of mild-ish abuses in both idioms.
I don't see any reason to prefer the first set to the second.
if ifelse(x<y, x>1, y<1):
t = ifelse(x<y, ifelse(y<z, z, y), x)
ifelse(x<y, (x,y), (y,x))
if (if x<y: x>1 else: y<1):
t = if x<y: (if y<z: z else: y) else: x
if x<y: (x,y) else: (y,x)
<unkind>I can see one way in which a builtin function might
lead to less abuse than a new expression: the builtin function
is uglier and less useful, so it will be used less, so it will
be abused less. I don't think that's a strong argument in its
Very subjective. All I can say is: I think the functional form
is ugly. I don't think functions of this kind fit well in Python.
I can't prove any of that, of course.
#4: confusing even in simple cases?
It seems to me that the "ifelse" function is worse than the
if: else: construct in this respect, because the difference
between the when-true clause and the when-false clause is
purely positional. From the million articles already posted
in this thread, I think it's clear that a general problem
with the punctuation-based solutions is that it's often
too easy to get the two consequents switched by mistake,
and an "ifelse" function will make that worse.
I also happen to find all the names proposed for the function
so far confusing; but then, names for functions with many
arguments are almost always insufficiently helpful. Hmm,
that suggests a way to make ifelse(,,) easier to get right:
keyword arguments. if(C, true=x, false=y). Bletch. :-)
In summary: all the arguments against new syntax apply
just as well to a new builtin, and a new builtin would be
useful in a strict subset of the cases where new syntax
could be. Remind me what *advantages* a new builtin
is supposed to have over new syntax, again?
 And not, so far as I can see, a subset where
inappropriate use is any less likely.
Gareth McCaughan Gareth.McCaughan at pobox.com
.sig under construc
More information about the Python-list