308 as a special case of 312 (was: Re: Pep 312 value)

[jerf at compy.attbi.com]

On Thu, 27 Feb 2003 16:23:54 -0800, Erik Max Francis wrote:

> andrew cooke wrote:
> 
>> someone did - see pep 312 http://www.python.org/peps/pep-0312.html
> 
> It's not entirely clear what this gains us except the omission of the
> keyword lambda.  It shortens code that uses it, but does so with a
> penalty of introducing more keyword-less, syntactic sugar.  Is PEP 312
> really a good idea?

It gains you your lazy ternary operator, and is *also* useful in other
circumstances. The "if" implementation is then merely a special case of
something else that is useful elsewhere.

Note, and I can't emphasize this enough, that **every** argument that can
be brought to bear against 312 applies equally to the ternary operator.
Newbie confusion, one more thing to learn, "what is it really good for?",
etc. I won't go so far as to claim that supporting the ternary operator
should imply some level of support for this, but it shouldn't be missed
that it's the exact same arguments against it. To wit:

> It's not entirely clear what the ternary gains us except the omission of
> a relatively short if-block.  It shortens code that uses it, but does so
> with a penalty of introducing more (potentially keyword-less,)*
> syntactic sugar.  Is PEP 308 really a good idea?

*: depending on the exact proposal chosen; I think those have mostly
fallen out of favor.

That read exactly the same as 308 criticisms, and is equally valid for the
same reasons.

I believe there are two importent differences between 308 and 312. One is
that lambda already exists, this is just a special-case respelling of it,
so technically, nothing new. (A ternary operator is new, as nothing
currently acts like that in Python; even _ and _ or _ is really two binary
operators strung together, each with an independent reason to exist.
Two, this is sufficiently more powerful then the ternary operator that it
might actually tip the balance in favor of adding it.

The 312 implementation of the ternary operator is even more concise in use
then many of the proposals. Plus there are obvious translations to
quaternary or n-ary operators:

def nary(cond, *args):

	return args[int(cond)]()

print nary (2, :x + 1, :x / 2, :x * 3)

not that anybody will actually use that, but the point is that it can be
used to build many useful things in addition to the special-case ternary
operator, not to mention the many other times such things can be useful.

I think it's also worth pointing out that the fact that there is pretty
much one syntax that makes sense for this, whereas the ternary operator
has still only converged to what, three or four strong proposals at least
(and I'm being generous)? This inability to pick one firmly says
something, I think, and it says something about 312 as well.

To date this is the only thing I'd vote +1 on, as the only proposal to
actually *balance* power with the additional complication in the language,
instead of adding complication to the language for a piddling feature it's
done without for 10+ years. If we *must* have support for a lazy ternary
operator, this is the way to go.

(Side note: It'll be interesting to see how the vote goes; clearly those
against 308 have stopped talking, making it seem as if support is now
overwhelming. It's impossible to know whether those still talking about it
are in the minority, the rest of us having largely said our piece and
moved on... ;-) and equally impossible to tell if support has been
overwhelming from day one, so no accusations of bias, please ;-) )