Comments on Version 2, Draft Pep for Deprecating Builtins

[Alex Martelli]

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

I don't get it.  Isn't apply the EASIEST built-in to show up as "useless
today"?  It DOES "take and apply a function argument" if that's what you're
targeting (a slant which would make it pretty hard to understand what pow
and divmod -- also, btw, used in programming that has nothing to do with
FP -- have to do with the rest).

Maybe there would be benefit in separating concerns:

A. what mechanism[s] could/should be used to move current builtins to
   other modules (possibly including a 'deprecated' one) without code
   breakage.  It seems to me that the .PTH mechanism gives possibly the
   smoothest road to that end, be it by adding 'from x import y, z' to
   the constructs it supports (my preference) or by exploiting its
   existing 'import x' support by providing suitable modules for 'x'

B. what if any current built-in functions that accept a function argument
   should be deprecated or otherwise moved.  Here it seems to me that
   the case is strongest for apply, weakest for callable (it COULD move
   to a new module intended for feature-resting, perhaps with some of
   operator's current contents -- but, should it?), and classmethod,
   staticmethod and property (all new shiny thingies), pretty good for
   filter (always well replaceable by a LC), not too bad for map (mostly
   replaceable by LC+zip), dubious for reduce (I _am_ surprised that
   reduce(operator.add, seq) now seems to be slower than a loop of
   for x in seq: result+=x, but still the reduce form might be said to
   be a more direct expression -- arguable, I admit).

C. what about current built-in functions that do not necessarily take a
   callable argument -- for each such function F, _is_ F important
   enough to need to be a built-in?  Why isn't, e.g., 'intern' in
   module sys, or other internals-related module -- how often does it
   get called, compared to uses of, e.g., sys.exit or sys.stderr?


Alex