Fill out the functional module

[collinwinter]

BPO	1412451
Nosy	@brettcannon, @rhettinger
Files	functional.patch: Patch to Modules/functionalmodule.c, against r42219 demo.patch: Add functional programming demos, against r42219

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-02-02.03:19:30.000>
created_at = <Date 2006-01-23.02:21:19.000>
labels = ['extension-modules']
title = 'Fill out the functional module'
updated_at = <Date 2006-02-02.03:19:30.000>
user = 'https://bugs.python.org/collinwinter'

bugs.python.org fields:

activity = <Date 2006-02-02.03:19:30.000>
actor = 'rhettinger'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2006-01-23.02:21:19.000>
creator = 'collinwinter'
dependencies = []
files = ['6973', '6974']
hgrepos = []
issue_num = 1412451
keywords = ['patch']
message_count = 9.0
messages = ['49386', '49387', '49388', '49389', '49390', '49391', '49392', '49393', '49394']
nosy_count = 3.0
nosy_names = ['brett.cannon', 'collinwinter', 'rhettinger']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1412451'
versions = ['Python 2.5']

[collinwinter]

This patch is an expansion of my earlier patch,
bpo-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.

[collinwinter]

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.

[collinwinter]

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.

[brettcannon]

Logged In: YES
user_id=357491

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

[rhettinger]

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.

[collinwinter]

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?

[rhettinger]

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.

[collinwinter]

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").

[rhettinger]

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.