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

[Alex Martelli]

Ville Vainio wrote:
   ...
> 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:

There are no way in which LC's and genexp can "take care of" CONSUMING
iterables and iterators -- they PRODUCE them (and itertools also do
some production, and, mostly, composable transformation).  map and
filter, sure; sum, reduce, min, max, can never be replaced by any
LC nor any genexp.  I think we need a separate module for _consumers_
of iterables/iterators, and I have repeatedly posted about it.  But,
sure, I'd gladly agree that there's no real call for any of these to
be a built-in.


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

I'd rather put map/filter/reduce in a 'legacy' module -- warts and
all, e.g. map's horrible habit of None-padding shorter sequences,
EEK -- and have a designed-from-scratch functional module without
the warts.  What about starting one as a sourceforge project, as I
mentioned elsewhere?


> There are also tons of functions that should be in sys, math or
> whatever:
> 
> reload, repr, divmod, max, min, hash, id, compile, hex...

Probably, yes.  What functions, as opposed to types, do you
think should absolutely be in the builtins rather than in a separate 
module, and (unless it's obvious) why?  Of course __import__ had
better stay or we won't be able to get anything imported, for
example:-).  The attribute-related functions hasattr, getattr,
setattr, and delattr, seem very fundamental (but I'd want the
same status for the item-functions currently over in operator),
as well as (at least some of them -- delattr isn't -- but I do
think that trying to discriminate too finely would make things
too hard to learn) very frequently used in code.  What else?
iter, len, pow [for the crucial 3-arguments case], range (or some
preferable variant that returns an iterator), and zip seem pretty
fundamental; chr and ord might be suitable as str methods (in
the case of chr, a staticmethod, no doubt).  Many functions that
are quite handy for interactive use, such as locals, globals,
dir, vars, ..., are not all that frequently used in programs --
so they might live in a module that the interactive mode gets
automatically, rather than being built-ins.

Having beginners learn 'import' before they do raw_input (or
output, which should also be a function, not a statement) may
not agree with somebody's didactics, so, we should consider how
to deal with those.

All of this would be perfect for the mailing list on Python 3.0
if the latter existed.  Posting it to c.l.py makes it unlikely
Guido will ever consider the discussion's resuts, anyway.  The
problem is that, with 3.0 at least 2 years away, there seems to
be little incentive to actually go and make such a list, so that
its archives may come in handy in the future.


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

Pretty bad, yes.  'apply' at least, while useless, doesn't make
Python's syntax any more complicated, while `...` does.


Alex