Least used builtins?

Lulu of the Lotus-Eaters mertz at gnosis.cx
Fri Jul 4 23:57:23 EDT 2003


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.

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.

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.

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.

All that said, I have neither any control of what happens, nor any
strong attachment to any of my suggested homes for (former) builtins.

|>     enumerate           itertools
|Again, this is idiomatic, and it belongs in builtins.

This one I strongly disagree with.  The fact enumerate is builtin is a
little bit of a wart.  It's really -just like- the family of functions
in itertools; only historical accident introduced it before itertools
came into existence.

|>     filter              functional
|Only because it's become redundant.

I don't at all think filter() is redundant... but I do think that a
'functional' module could grow a lot of extra useful capabilities
(currying, composition, etc).  The usual filter/map/reduce would make a
good start for such a module (and clean up the base interpreter for
those FP-haters out there :-)).

|Definitely not -- these are very important, importing them would be
|obnoxious.  Especially since "isinstance(value, str)" is the preferred
|technique over "type(value) is str".

Actually, I considered listing type() for desired removal to a module.
I suppose for consistency with my purport on isinstance() I ought to
advocate that.

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

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

Yours, Lulu...

--
mertz@  | The specter of free information is haunting the `Net!  All the
gnosis  | powers of IP- and crypto-tyranny have entered into an unholy
.cx     | alliance...ideas have nothing to lose but their chains.  Unite
        | against "intellectual property" and anti-privacy regimes!
-------------------------------------------------------------------------






More information about the Python-list mailing list