mcherm at mcherm.com
Mon Mar 24 19:27:42 CET 2003
> > 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
More information about the Python-list