Comment on draft PEP for deprecating six builtins

[Alex Martelli]

<posted & mailed>

Raymond Hettinger wrote:
        ...
>     There are separate motivations for each function.  One motivation in
>     common is that the number of total built-ins should be as small as
>     possible to limit the amount of "core language" one needs to know in
> order
>     to read code that is not module specific.

OK.  This may well be worth the substantial amount of work involved.

>     Pow() and divmod() are more related to math module functions than any
>     of the built-in functions.  In general, they are rarely used.  Because
>     the ** operator is available, the pow() function is rarely called
>     directly.

Built-in pow has a 3-argument form pow(a,b,c) which computes (a**b)%c far
more efficiently than separate operators can (for large integers).  There
are other obvious incompatibilities between math.pow and builtin pow:

>>> math.pow(2,3)
8.0
>>> pow(2,3)
8

Even though I use 3-arguments builtin pow reasonably often myself, that's
because I _am_ a combinatorics &c junkie.  I agree it's too rarely used to
be worth having it as a built-in -- importing it from a suitable module
would be fine.  But I double the suitable module is math, as this would
introduce further incompatibilities one way or another.  Module operator
might be most appropriate for both pow and divmod.


> Key Issue
> 
>     All of these functions have been in-place since the beginning, are
>     used
>     in mountains of code, and appear in every Python book.  The situation
>     would appear to be immovable.

Right.  Or at least, it should be moved slowly and with care.

 
>     I propose that a simple means be provided to re-enable those functions
> at
>     will when they are needed to run old code.  Add a command line option
>     -b and an equivalent environment variable, PYTHONBUILTINRESTORE which
>     would start-up Python by running:
> 
>         from functionals import map, filter, reduce
>         from math import pow, divmod
>         from deprecated import input

This would only make these 6 names available in __main__.  Do you propose
to inject them in every single module...?  Now THAT would be invasive
indeed.  No, they really need to go into __builtin__ if they're installed
for backwards compatibility.

I think a finer-grained mechanism might be preferable, and handled by
site.py / siteconfigure.py, perhaps, much like today are handles such
issues as sys.path normalization, and Unicode default-encoding.  The
former may be a more successful example than the latter, so maybe the
need might be best approached via an extension to the parsing and
handling of .PTH files.

Right now, .PTH files handle importing and path-setting needs of
installed packages.  Having them handle such packages' builtins-needs
as well seems a minor extension.  Should this slow start-up too much, maybe
some modest acceleration could be provided e.g. by sys.whatever helper
functions.  No objections to a PYTHONBUILTINS equivalent of PYTHONPATH,
in addition, for off-the-cuff needs.  Dunno 'bout the proposed flag: a
binary on/off switch seems too coarse-grained to be useful.


>     in perpetuity.  Like "from __future__" this mechanism can be used for
>     other deprecations, allowing the language to evolve without
>     accumulating clutter.

Exactly because of such "ongoing needs", the mechanism deserves careful
design.  No doubt more builtin candidates for deprecation can be proposed.

Take, for example, 'apply'.  What need does it serve, ever since the
forms *args and **kwds started applying to actual arguments (i.e., at
function-call time) as well as to formal arguments (i.e., at function
definition time)?  I.e., since 2.0 (or 1.6, I don't recall).  Indeed
that would have been my first candidate for built-in deprecation (also
for alphabetical reasons:-).

abs, buffer, chr, cmp, coerce, id, intern, oct, ord, are a few others
that might be worth thinking about in terms of frequency of need --
they're all needed some of the time, of course, but how often?  Often
enough to be warranted as built-ins?  I surely use, e.g., map, more
often than, e.g., cmp, coerce, or id.  Not to mention intern.  So why
should map go away and the others remain?  This is not meant to be a
rhetorical question, but to prompt active reflection/discussion/study.


Alex