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

[Terry Reedy]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:IT6tb.27445$hV.1005380 at news2.tin.it...
> 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 a liberating thought.  I sometimes forget that the only thing I
am really stuck with when programming in Python is the core syntax (in
the Ref Manual) and that I am free to wrap or replace anything else
(in the Lib Manual).  For a project I hope to start soon, I have been
worried about how to work around or explain away the deficiencies of
Python's of reduce().  Instead, I should just write the version I want
for my purposes (especially since speed does not matter).  So your
voluminous writing on this has benefited at least one person.

> 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?

I have thought some about this also.  Type objects could be put/left
in types, but as constructors, they are too useful and basic not to
have immediately available (unless builtins was reduced to nearly
nothing).

> Of course __import__ had better stay or we won't
> be able to get anything imported, for example:-).

Does it have to be in builtins for import statements to work?
Direct use of __import__ seems relatively rare.

>  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.

I had to re-lineate this to parse apart the three thoughts.  A static
frequency-of-use analysis for some large code collection would be
interesting.  I might write something eventually.

> iter
   I group this with type constructor objects, even though not one
itself
> len
   unless made a method, keep in
> pow [for the crucial 3-arguments case]
   very specialized and rarely used?  move to math as pow3
> range (or some preferable variant that returns an iterator)
   how about iter(3), etc, currently an arg type error?
   think of 3 as the sentinal value.
   is not typing '0,' worth the wartiness of optional first arg?
> and zip seem pretty fundamental
   agree except for pow

Terry J. Reedy