Least used builtins?
ianb at colorstudy.com
Sat Jul 5 09:43:18 CEST 2003
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__.
More information about the Python-list