On 19-Jun-07, at 12:13 PM, Bill Janssen wrote:
>> map (especially the new iterized version) is a frequently-used
>> builtin, while reduce is a rarely-used builtin that requires some
>> head-wrapping. It makes sense to me to move it out of builtins.
>
> I've never understood this kind of argument. Because most people
> don't program in Python, we should abandon the project as a whole?
No, but it certainly is an argument for not pre-installing a python
dev environment on all windows boxes, for instance.
Surely frequency of use should be at least _one_ of the criteria
involved in making decisions about including functionality as a builtin?
> For those who have "wrapped their head" around functional programming,
> "reduce" is a very clear and easy-to-understand primitive.
Granted. However, I claim that most python users would find a reduce
()-based construct less natural than an alternative, even if they
understand what it does. The suggestion is simply to move the
function to the "FP toolbox".
> But posting results gleaned from grepping over some random codebase
> written by someone who may or may not have done that head-wrapping at
> various points in time where some feature X may more may not have been
> available, seems even less of an argument.
reduce() was always available. But that isn't the point: I'm not
presenting the statistics as evidence of the entire python world, but
I think they still indicate _something_, if not only what are the
usage patterns of some type of python programmer (namely, one who is
familiar with FP and uses many of its concepts in their python
programming, though is by no means a disciple).
Stats from _any_ large python project is better than anecdotes.
Perhaps it would be better to turn to the stdlib (367289 lines)?
Python2.5/Lib $ pygrep -E '\breduce\(' | wc -l
31
15 of those are tests for reduce()/iterators
7 are in pickle.py (nomenclature clash)
Which leaves a few uses over binary operators:
./test/test_random.py: return reduce(int.__mul__, xrange
(1, n), 1)
./idlelib/MultiCall.py:_state_names = [reduce(lambda x, y: x + y,
./idlelib/MultiCall.py:_state_codes = [reduce(lambda x, y: x | y,
./idlelib/AutoCompleteWindow.py: elif reduce(lambda x, y: x or y,
./difflib.py: matches = reduce(lambda sum, triple: sum + triple
[-1],
self.get_matching_blocks(), 0)
Some trickiness in csv.py:
quotechar = reduce(lambda a, b, quotes = quotes:
(quotes[a] > quotes[b]) and a or b,
quotes.keys())
delim = reduce(lambda a, b, delims = delims:
(delims[a] > delims[b]) and a or b,
delims.keys())
modes[char] = reduce(lambda a, b: a[1] > b[1] and a or
b, items)
(which can be replaced with max(..., key=...)
reduce(lambda a, b: (0, a[1] + b[1]), items)[1]
(which could be written sum(x[1] for x in items)
> As I said, Guido's
> argument that "filter" (in the guise of [x for x in y if f(x)]),
> "any", and "all" are sufficient for almost every case seems like an
> interesting one to me, and he may well be right, but while we find
> out...
How will we find out, if reduce() continues to be availabe? <wink>
Regardless, that's my 2c. I don't think I have anythign further to
add to this (settled) matter.
-Mike
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
