A library approach to the ternary operator

[Alex Martelli]

David Abrahams wrote:
   ...

>> somewhat important to pick a better name for the function...!).
>> Another likely name might be "pick".
> 
>         y = choose(x < 0 and [22.5] or [f(x)])
>         y = ternary(x < 0 and [22.5] or [f(x)])
>         y = pick(x < 0 and [22.5] or [f(x)])
>         y = cond(x < 0 and [22.5] or [f(x)])
>         y = if_(x < 0 and [22.5] or [f(x)])
> 
> I guess I like the last two, and the last one best of all, because
> in my mind there's a nice association between the function name and
> the adjacent condition.

My preferences differ -- using an ordinary, well-pronounceable
English word such as 'choose' or 'pick' seems to make for clearer
and more readable code than arbitrary abbreviations such as
'cond' for 'conditional' (no doubt familiar to LISPers, but, since
the function's workings are SO different from Lisp's COND, I do
not think the familiarity is necessarily an advantage) or things
such as 'if_', hard to pronounce distinctly from keyword 'if'.

Of the above proposals, I think 'choose' would probably make it
likeliest that the function becomes widely used, 'if_' would
probably make it least likely.  Matter of opinions, of course.


>>> to be worth using.  Having a function name ("select") there gives us
>>> something to attach a nice verbose comment to, while the above, since
>>> it uses only language primitives, remains obscure.
>>
>> Yes, I concur.  Moreover, this ternary.py can easily be widely
>> spread and popularized
> 
> or spurned, as the case may be ;-)

Yes, if people don't like it they won't use it, and need never even
bother to learn it -- it gives Pythonistas a chance to make their
choices in the matter entirely.  That's part of why I like it.


>> to establish a usage base for 'choose' IF people like the approach
>> (I'm not gonna guess if they will) -- this may help make a case for
>> 'choose' as a built-in, later, if and only if people like and use it
>> so much as to warrant that.
> 
> It's always nicer to have a transition plan that goes through a
> library-only approach first without making core language changes.
> That gives the concept a chance to live or die on its own without
> forcing people to accept more than they can stomach.

Exactly!  Well put.


Alex