Too much builtins (was Re: Python's simplicity philosophy

[Ville Vainio]

Douglas Alan <nessus at mit.edu> writes:

[reduce]

> >> If someone can't understand this quickly, then they shouldn't be
> >> programming!
> 
> > Again, it's not "can't", it's whether they need to or not.
> 
> If you don't want to learn a cool concept that will only take you 60
> seconds to learn, then you shouldn't be programming!  Or you can stick
> to loops.

As far as reduce goes, ppl will undoubtedly take a look at the
description, understand it in well under 60 seconds, can't think of
any use for the feature during the next 60 seconds (that wouldn't be
clearer with explicit iteration), and forget it soon after turning the
page. I didn't forget it, just wondered why such an oddball feature
was a builtin. Obviously reduce can rock someone's world, but life is
too short to bother if it doesn't rock yours.

> and powerful feature with a slew of specific, tailored features.  If
> reduce() can be relegated to a library or for the user to implement
> for himself, then so can sum().  If the language is to only have one,
> it should be reduce().

I also think that reduce, sum, map and filter (and lots of others,
__builtins__ has *too much stuff*) should be removed from builtins,
but that will probably take some time (1997 years?). LC's and genexpes
will take care of most of that stuff. And people can always do:

from funtional import *  
# map, filter, reduce, curry, ... (I want lots of these :)

There are also tons of functions that should be in sys, math or
whatever:

reload, repr, divmod, max, min, hash, id, compile, hex...

What's your pet deprecation candidate? I have always thought
`backticks` as repr has got to be the most useless feature around.

-- 
Ville Vainio   http://www.students.tut.fi/~vainio24