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

[Gareth McCaughan]

Aahz wrote:

>  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):
        stuff
    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):
        stuff
    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
favour.</unkind>

#3: ugliness.

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[1]. Remind me what *advantages* a new builtin
is supposed to have over new syntax, again?

    [1] 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