Comment on draft PEP for deprecating six builtins

[Raymond Hettinger]

"Alex Martelli" <aleax at aleax.it>
> There are other obvious incompatibilities between math.pow and builtin
pow:
>
> >>> math.pow(2,3)
> 8.0
> >>> pow(2,3)
> 8

That's a problem whether or not this proposal is adopted.
Like 'open' in the os module, 'pow' is a high risk candidate from for being
clobbered by a 'from math import *'.

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

Good point.  I'll revise accordingly.

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

Agreed.  We need some sort of undeprecate mechanism by the time the
functions disappear (around Py2.6 or so).  Site.py seems like a better
approach than I proposed.

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

Yes!

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

I picked the first six candidates for re-assignment or elimination.
No doubt, there will be others.

Thank you for the insightful comments.  I'll revise the draft accordingly.


Raymond Hettinger