This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Fill out the functional module
Type: Stage:
Components: Extension Modules Versions: Python 2.5
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: brett.cannon, collinwinter, rhettinger
Priority: normal Keywords: patch

Created on 2006-01-23 02:21 by collinwinter, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
functional.patch collinwinter, 2006-02-01 10:22 Patch to Modules/functionalmodule.c, against r42219
demo.patch collinwinter, 2006-02-01 10:27 Add functional programming demos, against r42219
Messages (9)
msg49386 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-01-23 02:21
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/ 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/ 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

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.
msg49387 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-01-23 12:55
Logged In: YES 

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.
msg49388 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-02-01 10:27
Logged In: YES 

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.
msg49389 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2006-02-01 19:15
Logged In: YES 

Do note that the function names do not follow the naming
convention specified in PEP 8.
msg49390 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2006-02-01 19:59
Logged In: YES 

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.
msg49391 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-02-01 22:22
Logged In: YES 

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?
msg49392 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2006-02-01 23:09
Logged In: YES 

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 

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.
msg49393 - (view) Author: Collin Winter (collinwinter) * (Python committer) Date: 2006-02-02 00:53
Logged In: YES 

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").
msg49394 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2006-02-02 03:19
Logged In: YES 

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.
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42822
2006-01-23 02:21:19collinwintercreate