(no subject)

[Michael Chermside]

> > Yes, I concur.  Moreover, this ternary.py can easily be widely
> > spread and popularized
> 
> or spurned, as the case may be ;-)
> 
> > 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.

Not in all cases. Whenever you have a significant piece of functionality
-- socket support, perhaps, or threading, or Date handling -- it makes
lots of sense to develop it as a library and then see how much use the
library gets before adding it to the core language.

But some features provide almost no functionality -- conditional
expressions are clearly an example of this. In these cases, the utility
of the feature is based on its universal availability and recognition.
If the feature is available in a library it's just not worth using.
For instance, suppose that the print statement were provided as
functionality in a library -- NO ONE would use it, everyone would
simply use the built-in sys.stdout.write() instead. Print adds no real
functionality over sys.stdout.write(), just a convenient way to access
that functionality, built into the language.

I think a conditional expression falls into this category -- if such
an expression existed in the language, I think there are times when
it would be clearer and more readable to use it. But if I had to import
a module, then it would be LESS clear than using an if statement.

-- Michael Chermside