Comment on draft PEP for deprecating six builtins

[Raymond Hettinger]

Please send me comments on a draft PEP deprecating
and relocating six built-in functions.  The text file is at:
http://users.rcn.com/python/download/deppep.txt

It is also listed below.


Raymond Hettinger

-------------------------------------------------------------------

PEP: XXX
Title: Deprecate Six Built-ins
Version: $Revision: 1.1 $
Last-Modified: $Date: 2002/04/28 19:42:56 $
Author: python at rcn.com (Raymond D. Hettinger)
Status: Draft
Type: Standards Track
Created: 28-Apr-2002
Python-Version: 2.3
Post-History:


Abstract

    This PEP proposes to compact the list of built-in functions through
    relocation and deprecation.  map(), reduce() and filter() would move to
a
    separate module for functionals.  pow() and divmod() would move to into
    the math module.  input() would be eliminated altogether.



Rationale

    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.

    The functionals (map, filter, and reduce) had greater importance prior
to
    the introduction of list comprehensions which are now the preferred (and
    more readable) approach.  Limits on the number of built-in functions
    prevented the addition of other functionals which may have be useful
when
    that style of programming is needed.  Creating a separate module allows
    room for a large variety of functionals (e.g. fold, head, tail, take,
    drop, etc.) to be introduced without cluttering the built-in namespace.

    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.

    Input() is easily replaced by eval(raw_input()).  It has few legitimate
    uses and presents a security risk in most programs where it is used.
    Though the risks are well documented, experience on python-tutor and
    help at python.org indicates that new users frequently use input() when
    raw_input() was intended and that they are unaware of the embedded
eval().



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.

    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



Implementation and Deprecation Timetable

    The module additions would go into Python 2.3.  All six functions would
be
    left intact and raise deprecation warnings in Python 2.3 and 2.4.  The
six
    functions would be removed in Python 2.5 (having allowed two versions
and
    a full year for code updates).  The -b command line option and related
    environment variable would go into Python 2.3 and remain available
    in perpetuity.  Like "from __future__" this mechanism can be used for
    other deprecations, allowing the language to evolve without accumulating
    clutter.



Copyright

    This document has been placed in the public domain.



Local Variables:
mode: indented-text
indent-tabs-mode: nil
fill-column: 70
End: