Comments on Version 2, Draft Pep for Deprecating Builtins
Alex Martelli
aleax at aleax.it
Mon Apr 29 05:53:33 EDT 2002
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
More information about the Python-list
mailing list