Least used builtins?

[Ian Bicking]

On Sat, 2003-07-05 at 02:18, Dr. David Mertz wrote:
> |just means that "core Python" (i.e., the subset of Python's
> |standard library used by 95% of significant code)
> 
> Nah... I think the ratio is exactly the opposite.  Putting all 
> the things I mentioned before into outside modules would require 
> no modification at all to 95% of my modules (well, excluding some 
> unusual introspective code I've written).  And the 5% that would 
> be affected would need one extra import line at top (unless some 
> mechanism like startup.py eliminated even that one line).

When I say 95%, I mean the things that show up somewhere in 95% of all
Python applications -- not in 95% of all modules, but somewhere in the
application.  Which is to say, most applications would require human
intervention to be ported to any environment where those functions
weren't available.  If a function or type hits that 95% (or whatever
number), I don't see a big benefit to keeping it out of builtins, unless
there's a really good conceptual reason that it belongs somewhere else. 
Some of these, like classmethod, aren't used that often, but will be --
Python programmers on the whole still haven't taken new style classes to
heart.  I think enumerate could be there too -- I've certainly seen the
pattern in most code, and eventually one would hope that pattern where
enumerate is useful will be increasingly be implemented with enumerate.

> |I disagree.  There's nothing saying you have to describe
> |everything in __builtins__ -- using that module as a teaching
> |outline is surely a bad idea.
> 
> As soon as a new programmer gets an interactive shell they run 
> 'dir()'.  And then they wonder what all those names are about.  
> And a natural presentation puts everthing builtin together, for 
> example in a reference text.

That's a reference text, where a larger size really doesn't matter.  A
good presentation will tell the programmer to ignore most of those, or
that some will only be explained later.

> |That describes most of my modules!  I seldom import sys -- I probably
> |import os much more often, but certainly not half of the time. 
> 
> Really?! How do you get sys.argv then? Or sys.stdin? Admittedly,
> a simple 'print' usually gets you the sys.stdout you want, but
> what about sys.stderr?

I usually don't need those.  Those are only needed for the front end of
a command-line application, for the most part.  One module among many. 
The rest might deal with a file-like object, but I wouldn't hardcode
sys.stdin or sys.stdout.  And sys.argv is certainly only useful for a
certain context (a command line program) but even then I'd never use it
outside of __main__.

  Ian