[issue11011] More functools functions

[Raymond Hettinger]

Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Some of these have been proposed and rejected before.

Compose has a problematic API because the traditional order of application in mathematics is counter-intuitive for many people.

Const seems reasonable except that we already have ways to do it:  
     twos = lambda :2
     twos = itertools.repeat(2).__next__
The principal use case for const is with map() and itertools.repeat() is already targeted at that use-case:
     cubes = list(map(pow, range(10), repeat(3)))

Flip would be nice on occasion:
     colorseq = list(map(flip, enumerate(
       'red orange yellow green blue indigo violet'.split())))

Identity is problematic for a few reasons.  First, there doesn't seem to be one signature that fits all use cases:
     identity1 = lambda *args:  *args   # always returns a tuple
     identity2 = lambda arg:  arg       # always returns a scalar
Also, the availability of 'identity' seems to encourage bad design.
Speedwise, it is usually better to have two paths (predicate is None vs some given predicate) than have an identity function default (predict=identity).  See the itertools module for examples.

Trampoline is interesting, but the use case doesn't seem to arise much in Python programming and when it does, it is usually clearer to write:
    for f in get_actions():
        f()
That straight-forward code is superior, not just because of its readability but also because it is easily modified to handle return values being feed in to consecutive calls, adding optional and keyword arguments, introducing logging, etc.  

In short, some of these constructs are better suited for languages that a more purely functional in nature.  Those don't treat scalar arguments differently than multiple arguments, those don't use keywords or optional arguments, currying can be done cleanly etc.

Experiences with the itertools module have shown than not all of the usual favorite functional gizmos fit well in the Python language.  They are tempting toys, but typically don't beat regular, clean Python code.

One last comment, any time a group of interoperative tools is proposed, I think it absolutely necessary to construct a bunch of sample code to exercise the APIs working in concert with one another.  With the itertools module, considerable effort was directed at designing a toolkit with cleanly interoperative parts.

Also, when proposing something that changes the fundamentals of how people would design their programs, I think it is necessary to scan real-world code to find many examples where the code would be much improved if it used the new constructs.  (This is similar to the notion of a Phase III clinical trial -- even if something works, it needs to be shown to be better than existing alternatives).

----------
nosy: +rhettinger
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11011>
_______________________________________