Comments on Version 2, Draft Pep for Deprecating 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

This is version two and incorporates the comments received
from David, Alex, Brian, Martin, and Chris.

It is also listed below.


Raymond Hettinger

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

PEP: XXX
Title: Deprecate Six Built-ins
Version: $Revision: 0.2 $
Last-Modified: $Date: 2002/04/29 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 operator 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.  Reduce is easily (and more clearly) replaced
by
    an equivalent for loop.  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 operator 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 (unless the optional third argument is needed).  Another reason
    to move pow() is that is conflicts with the identically named, but
    semantically different function in the math module.  As a builtin, pow()
    is in a vulnerable position for getting clobberred by a
    "from math import *".

    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 -- Something equivalent to:

        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.4 and 2.5.  The
six
    functions would be removed in Python 2.6 (having allowed three versions
    and over a year for code updates).  The restore builtins mechanism would
    go into Python 2.4 and remain available in perpetuity for other
    deprecations, allowing the language to evolve without accumulating
    clutter.


Discussion

    Q.  Why wasn't zip() included.
    A.  It doesn't take and apply a function argument.  Also, it is used in
        non-functional programming to neatly code lockstep iteration.

    Q.  Why wasn't apply() or oct() included?
    A.  I picked six candidates for relocation or elimination based on
        whether I could make a case for them.  No doubt there will be
others.



Copyright

    This document has been placed in the public domain.


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