Comments on Version 2, Draft Pep for Deprecating Builtins

[Terry Reedy]

"Raymond Hettinger" <python at rcn.com> wrote in message
news:aaiu6e$pfr$1 at bob.news.rcn.net...
> 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

-1 on proposal as stated.

I agree with Alex M. that major concerns should be separated.

First, should we open up a can of worms and posssibly set off a
firestorm by executing
builtins = filter(keep, builtins) #  or is really better to say
builtins = [func for func in builtins if keep(func)] # or even
builtins = [func for func in builtins if not remove(func)]

Second (given First is true), what should be general mechanism and
philosophy.  Should we reduce gradually or just once (at 3.0).  Should
we keep unless there is a reason to remove, or remove unless a reason
to keep.  We could put *everything* in a separate module.  I am not
suggesting that, but it seems to me that builtins *could* easily and
justifiably be reduced by about half, given that we get started and go
beyoun the most obvious and uncontentious.

Third (having answered Second) is the contentious fight over fleshing
out the body of keep() or remove().  Input() is obvious.  So,
arguably, is apply() -- if the criterion for removal is 'now obsolete'
(in this case because of a syntax addition) rather than 'seldom used
in the past'.  On the otherhand, using divmod() has been touted as a
way to insulate onself from the int division change, so it would seem
ungracious to 'deprecate' it anytime soon.

Terry J. Reedy