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

[Alex Martelli]

Terry Reedy wrote:

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

Glad to hear this.


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

Yes, I think the types should stay right in the builtins.


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

No, it would be technically possible to redefine "import"'s semantics 
to take it from anywhere.

> Direct use of __import__ seems relatively rare.

It depends on what you're comparing against, I guess, but yes,
it's not a staple of most programming styles.  It's there more
to be overridden than to be directly called.


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

I'm pretty sure that checking for existence and getting the value
are more frequent operations than setting a new value, and that, in
turn, more frequent than deletion.  That's "just the way it is" --
it's much the same as in, e.g., SQL (SELECT overwhelming more used,
INSERT and UPDATE less often, DELETE quite rarely).


>> iter
>    I group this with type constructor objects, even though not one
> itself

It's a factory function, yes.  Not technically a type, but the
connection in terms of use is indeed close.

>> len
>    unless made a method, keep in

A method of every sequence and container on Earth?  Eeek.

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

Yes, I can see pow could be controversial here.


Alex