[Python-Dev] PEP 322: Reverse Iteration

[Neal Norwitz]

On Tue, Nov 04, 2003 at 12:31:02PM -0800, Guido van Rossum wrote:
> 
> We still need to contain the growth of the language, and that
> includes the set of builtins and (to a lesser extent) the standard
> library.  Maybe you can propose to take away an existing builtin to
> make room *first*.

Oh boy!  You opened a can of worms. :-)

I won't suggest adding any builtins (including reverse), but I will
suggest (re)moving quite a few.  This is a suggestion towards the
future.  I realize nothing should be removed in 2.4.

Currently, we have
        >>> len(filter(lambda x: x[0].islower(), dir(__builtins__)))
        66

Below are the builtins I'd like to see removed.  I've given a short cryptic
comment for many.  Several can be removed because they become redundant
(e.g., long, open, raw_input, xrange).

        apply, 
        buffer (or replace implementation with something useful), 
        coerce, intern,
        long (int/long unification),
        open (same as file) (maybe pending deprecation in 2.4?), 
        raw_input (become input),
        reduce (assuming another mechanism will exist) (deprecate 2.4?),
        reload (some other mechanism related to import?),
        slice (or maybe move to a module),
        xrange (unify with range)

For 2.4 I'd suggest we officially deprecate: apply, coerce, intern.
Pending deprecation for: open, reduce, and maybe slice.

I don't know how to deal with input/raw_input.  While it seems goofy,
perhaps something like this:
        2.4 deprecate input
        2.5 make input == raw_input, pending deprecation for raw_input
        2.6 deprecate raw_input
        2.7 remove raw_input

Or just wait for 3.0. :-)

Math related builtins: abs, complex, divmod, pow, round, sum
        Perhaps, some of these could be moved to a module

Move these to sys?:   hash, id
Formating utilities (move some/all to some module): 
                       chr, hex, oct, ord, repr, unichr
        Not sure about these, chr, oct and unichr seem
        to be the least used in my code.

For any builtin that's moved, make a pending deprecation
when used as a builtin for 2.4 and full deprecation for 2.5.

For anything that is likely to be (re)moved in 3.0, perhaps
we should at least use pending deprecations now.  Even
if we don't know what will happen, at least people start
getting an idea of the direction for the future.

Doing-my-best-to-shrink-the-language, :-)
Neal