Comment on Draft Pep ver 4 -- Psuedo Deprecations of Builtins

[Jeff Shannon]

In article <ucuagjg8it3v4b at news.supernews.com>, 
johnroth at ameritech.net says...
> 
> "Raymond Hettinger" <python at rcn.com> wrote in message
> news:aan5hv$aor$1 at bob.news.rcn.net...
> > Reading all of the posts on the deprecation pep shows that there is a
> > tension between ability to remove cruft versus breakage of old
> programs.
> > My idea for getting the best of both is psuedo-deprecation.
> >
> > Let's take anything that shouldn't be there anymore (read as anything
> that
> > wouldn't be put in again if we were doing this from scratch) in a
> separate
> > section of the library reference called Obsolete Constructs.  We'll
> pull it
> > out of the main body of the docs and the tutorial; remove uses of it
> from
> > the Python library; and ask authors not to even mention the
> > psuedo-deprecates
> > (except in a separate section devoted to being able to read old code).
> 
> Agreed.
> 
> > I no longer think map(), filter(), and reduce() should even be
> > psuedo-deprecated,
> > but apply(), oct() and hex() are prime candidates.  The input()
> function
> > should
> > still be considered for genuine deprecation and deletion, but that
> reflects
> > my
> > view of input() as a bug.
> 
> I strongly disagree about apply(). The only use I've found for it
> varies the function which it calls, not the parameter lists! Having
> variable parameter lists doesn't hack it - I need the variable
> function.

But variable functions can be had simply by binding a name to 
whatever function you want, or storing a function object in a 
sequence/mapping, or any number of other ways.

>>> def func1():
... 	print 'One!'
... 	
>>> def func2():
... 	print 'Two!'
... 	
>>> functions = [func1, func2]
>>> functions[0]()
One!
>>> functions[1]()
Two!
>>> 

How does using apply() improve on this?

-- 

Jeff Shannon
Technician/Programmer
Credit International