Logged In: YES 
user_id=80475

If you want to force this through over my objections, a 
PEP is a way to do it.  Also, you can start a conversation 
on comp.lang.python, marshal support, and then take it to 
python-dev and ask for Guido to pronounce on it.  

However, do consider that there may be merit to my 
suggestion to first offer it as a third-party module.  
Then, if it is wildly successful, popular, and bug-free, 
there will be a better case for adding it to the standard 
library.

At the very least, there should be an exercise to scan 
volumes of real-world code and find-out how often code 
would be improved by having these functional constructs. 

I think you will find that several of the functions are 
only of academic interest in a Python context.  The 
existing language is already very accommodating.  List 
comps and genexps reduce the need for functional 
constructs -- in particular, they allow arbitrary 
expressions and allow the programmer to avoid embedded 
lambdas and calls to the operator module.

Also, do consider that these functions can be hard to use 
because it is difficult to remember the argument order, 
processing sequence, and handling of end-cases.  That is 
why Guido and so many others hold reduce() in such low 
regard.  Similar thoughts apply to foldr() and foldl().

I sense a desire to force this through because a) it can 
be done and b) these constructs have been successful in 
other languages.  I do not sense a motivation based on 
user needs or the inability of the existing language to be 
able to solve certain classes of problems.  To some 
degree, this programming style is at odds with the 
language and its goals for readability.

A recurring design premise for Python is that is easier to 
remember how to compose or flip using pure Python than it 
is to learn and remember where to find a pre-made version 
in some module somewhere.  These tools are so simple that 
it is hard to argue that they add any value at all.