This patch is an expansion of my earlier patch,
#1410119, and should be considered to supersede it.

This patch fixes a reference leak in the earlier
implementation of foldr. The reference leak was tricky
to trigger, but existed.

In addition, this patch breaks the functional module
into two parts: Modules/_functionalmodule.c and
Lib/functional.py. The latter is for list-producing
functions which are better implemented as generators
(to make them lazier), while the former is reserved for
non-list-producing functions, written in C for speed.
Lib/functional.py imports the `_functional` module
generated from Modules/_functionalmodule.c.

The total contents of the functional module:
+ compose
+ concat
+ concatMap
+ cycle
+ drop
+ dropWhile
+ flip
+ foldl
+ foldl1
+ foldr
+ foldr1
+ id
+ iterate
+ partial
+ repeat
+ scanl
+ scanl1
+ scanr
+ scanr1
+ take
+ takeWhile

In addition to a full test-suite and latex-formatted
documentation for all functions, this patch also adds a
functional/ directory to Demo/ and populates it with
examples.

After applying this patch, the existing
Modules/functionalmodule.c should be removed and
replaced with the attached _functionalmodule.c (sorry,
I couldn't figure out how to make this show up in an
svn diff reliably).

The patch is against svn revision 42148.

Logged In: YES 
user_id=1344176

I've broken the main functional.patch into two subpatches.
demo.patch creates and populates the Demo/functional/
directory, while functional.patch does all the rest.

Both patches are updated to r42155.

Logged In: YES 
user_id=1344176

I've updated functional.patch to remove functions that are
already handled in itertools. The remaining functions which
had been implemented in Python have now all been recoded in
C. All functions have seen implementation improvements since
the last version of the patch.

This patch removes the need for the icky "manually add
_functionalmodule.c" part of the original patching
instructions. No special actions are necessary now.

The patch is against svn revision 42219.

Logged In: YES 
user_id=357491

Do note that the function names do not follow the naming
convention specified in PEP 8.

Logged In: YES 
user_id=80475

I am strongly against the broad expansion of this module 
until it has lived for some time as a successful, mature, 
well-loved stand-alone module.

Each addition needs to be fully thought-out in terms of 
use cases and evaluated for clarity/efficacy against 
existing Python solutions.

At some point, there was a substantial discussion on just 
the compose() function.  While it seems basic to 
functional programming, it was found not to be necessary, 
and not represent much of an improvement over a simple 
lambda expression.  Also, a number of folks have 
difficulty remembering whether compose(f,g) means f(g(x)) 
or g(f(x)).

Also, some of these entries duplicate those in the 
itertools module.  It is not in Python's best interests to 
provide several ways of doing the same thing.

Logged In: YES 
user_id=1344176

As stated in an earlier comment, I had already noticed the
duplication and removed the relevant functions from my
patch. The current member list is foldr, foldl, partial,
flip, compose, id, scanl and scanr. All of these are
implemented in C, removing the need for the special
instructions outlined in the original message body.

Is it necessary to go through the PEP process to see any of
these members included in the module?

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.

Logged In: YES 
user_id=1344176

I'm not going to force it; somehow pissing off the
python-dev crowd doesn't seem like the best route ;) This
work is based more on scratching an itch of mine, a desire
for more functional-style tools in Python.

In any case, I've just released version 0.5 of just such a
third-party module to PyPI (the name is "functional").

Logged In: YES 
user_id=80475

Good luck with the module.  Let us know how it fares in 
the real-world, whether it turns out to be indispensible 
or just a curiousity.