[Python-3000] Python 3000 Status Update (Long!)

[Mike Klaas]

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