Least used builtins?

[Ian Bicking]

On Fri, 2003-07-04 at 22:57, Lulu of the Lotus-Eaters wrote:
> I don't think any of these are a big deal.  But I see several
> motivations for moving a number of the builtins that Bicking disagrees
> on.  The breakage could be made small to non-existent by including a
> bunch of such things in a file like startup.py that gets loaded
> automatically, but that can be changed in principle.
> 
> One general point is that getting rid of builtins can make a minimal
> Python footprint smaller (and load times slightly faster probably).  For
> embedded systems, handhelds, etc. reducing the required memory usage is
> a good thing.

It would be more correct to say that by having these in separate
modules, it is easier to find code that uses them so it can be adapted
to this minimal environment.  Actually removing many of those builtins
would create a version of Python that would not run most of the Python
code out there -- moving things into different modules doesn't change
that, it just means that "core Python" (i.e., the subset of Python's
standard library used by 95% of significant code) is split among more
modules.  Of course, some stuff in builtins is obviously cruft, but not
a huge amount of it.

> A second issue is the PyPy project.  I think it dovetails with that
> project to move everything that is a likely candidate for
> reimplementation *in* Python into non-core modules.  Doing this is not
> strictly a requirement for PyPy, but it fits the style of thinking.

The premise of PyPy is that *everything* is a likely candidate for
reimplementation in Python.  It shouldn't matter if it's a builtin.

> A third matter is my support for the function decorator/mutator idea.
> classmethod, staticmethod, and property are nice method mutators, but as
> a number of people pointed out in that thread, they are not the only
> such modifiers one can imagine.  Moreover, you can implement these in
> Python (I incorrectly once doubted this), so spinning them out of core
> makes sense from a #2 perspective.

Certainly more operations are possible, useful, and to be encouraged. 
But it's also reasonable for a small set of those to become idiomatic
and widely understood -- classmethod, staticmethod, and property are all
general enough to apply.

> Yet a fourth matter is that I think it would be slightly easier to teach
> Python to beginners if __builtins__ did not include a number of
> functions that were extremely difficult to explain to novices... and
> that are really only of use to fairly expert Pythoneers.  I find that
> callable, classmethod, id, intern, and a number of others fall in this
> category.  My thinking is that anything meant for experts should need to
> get imported by specific request.

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.  You should feel entirely free to ignore many of those builtin
functions as you like -- certainly some (like intern) *should* be
ignored for as long as possible, ostracized even :)

> |[super] Again, highly idiomatic, programmers should be discouraged from
> |using this name for anything else
> 
> Indeed.  But non-advanced programmer won't be using it for its builtin
> meaning either.  Just look at all the threads by quite sophisticated
> Pythonistas trying to clarify exactly what super() really does.  You
> cannot even understand this function without first getting C3
> linearization (and even then, figuring out what the different calling
> forms all do is still tricky).

That's a problem with super, not with its place in builtins.  Super is
kind of a sad retort to a perceived omission in the language...

> |zip, like enumerate, is idiomatic -- importing it does not imply
> |anything about your code, that it comes from itertools lends little
> |insight into what zip does.
> 
> Actually, I don't think a separate zip/izip does any good, nor
> range/xrange.  But those are more historical accidents.  I wouldn't mind
> seeing itertools have the same kind of status that sys does now.  What's
> the last script you wrote that didn't import sys?  You don't technically
> need it... until you want to do something with input, output or
> arguments :-).

That describes most of my modules!  I seldom import sys -- I probably
import os much more often, but certainly not half of the time.  Sys is a
good example of what would worry me about a module refactoring -- sys
just feels like a dumping ground for everything that doesn't quite
deserve to be in builtins, but doesn't really feel like it's anything
else either.  There's no cohesion, but it's considered hidden because
it's in a module of its own.

  Ian