Comments on Version 2, Draft Pep for Deprecating Builtins

[Gareth McCaughan]

Raymond Hettinger wrote:
> 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

I'm replying to c.l.py instead of directly to Raymond
in case I'm missing some point here.

Executive summary: -1.

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

No. |reduce| is easily replaced by an equivalent for-loop,
yes (except that the equivalent for-loop can't be used in
contexts where only an expression will do, but I can't think
of an instance where this is a problem that isn't terribly
bad style), but the equivalent for-loop is not always clearer,
is always more verbose, and is always slower. Clarity is not
the *only* goal in programming, even in Python.

Random observation about |reduce|: almost every use of
|reduce| in code I've written has opearator.add as the
first parameter. Maybe we should add a |sum| builtin. :-)

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

So create the separate module and put map, filter and reduce
in it as well as in __builtins__.

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

Eliminating |input| would be a major improvement to the language,
*provided* we get something that does what |input| should have
done. Unfortunately, what with unary minus and complex numbers
and lists and tuples and everything else being handled in the
expression eval rather than the parser, this isn't as trivial
as one might think.

To expand: we could really do with something that lets the user
enter "46" or "0x1234" or "'walrus'" or "-2+6j" or "[1,'a',{3:4}]"
and returns the same as |input| does for those, but that doesn't
permit "f(123)" or "2**2002" or "[x for x in [1,2,3]]".

>     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

Such as? Note that whatever you choose, you also need a way to
make it the default reasonably robustly. Preferably one that
doesn't evaporate if someone upgrades her version of Python or
changes to using a new shell, and preferably one that works on
all platforms Python supports. This sounds really difficult to
me; I'll be interested to see how it can be done.

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

There appears to be a missing step in the logic here.
Is there supposed to be some fundamental law saying
that it's bad for anything that takes and applies a
function argument to be in __builtins__? I know some
people suffer from lambdaphobia, but this is going a
bit too far.

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

Couldn't these two Q&As be replaced by

    Q. Why did you choose those functions and not (say)
       apply or zip or oct?
    A. I just did.

?

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
.sig under construc