Third Draft: Pep for Deprecating Builtins

[Erik Max Francis]

Raymond Hettinger wrote:

> From the comments, I've learned:
> 
> 1. map, filter, divmod, and pow may be immovable and should
>     be left alone.
> 
> 2. reduce has fewer friends, but should probably also be
>     left alone
> 
> 3. input() has almost no supporters and should probably be
>     deprecated.  it is security risk, a trap for new users, easily
>     replaced with eval(raw_input), and is named in a way that
>     doesn't suggest that eval is occurring.
> 
> 4. apply() was repeatedly suggested as another candidate for
>     deprecation since the * and ** forms make it obsolete
> 
> 5.  oct() is another candidate based on the rarity of usage
> 
> 6. command line options and environment variables are
>     universally hated, so this idea is dropped
> 
> 7. the language needs some means of deprecating so that clutter
>     does accumulate.  that means needs to be well documented,
>     have a long, slow phase-in, and have a mechasism for
>     restoring old behavior if it is ever needed.

So far I haven't seen any indication that what you're talking about
moving qualifies as "clutter."  If your best attempt at cleaning up
clutter in a language is moving a _handful_ of builtlins to a submodule,
I'd say that the language doesn't have much clutter at all.

What is the supposed advantage to moving, say, map to a module named
functional?

Deprecating oct doesn't make any sense to me at all.  You already have
hex; having oct simply makes good sense and improves symmetry.  Getting
rid of (or simply moving to a module) oct but not hex makes no sense to
me whatsoever.

-- 
 Erik Max Francis / max at alcyone.com / http://www.alcyone.com/max/
 __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/  \ Life is one long process of getting tired.
\__/ Samuel Butler
    Interstelen / http://www.interstelen.com/
 A multiplayer, strategic, turn-based Web game on an interstellar scale.