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.

classification
Title: Extend the functools module with more higher order function combinators
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.8
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: rhettinger, tpleyer
Priority: normal Keywords: patch

Created on 2019-01-29 22:08 by tpleyer, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 11699 closed tpleyer, 2019-01-29 23:40
Messages (3)
msg334536 - (view) Author: Tobias Pleyer (tpleyer) * Date: 2019-01-29 22:08
The partial function is a typical example of a higher order function: It takes a function as argument and returns a function. As the name of the functools module suggests its purpose is to provide tools for working with  functions. This should, in my opinion, include a much bigger set of higher order function combinators as they are known from functional programming.
As a start I suggest to add the following functions:

identity: The identity function which returns its input
compose: Create a function pipeline (threaded computation)
sequence: Use compose without binding it to a variable
msg334540 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-01-29 23:49
I believe each of these has been discussed and individually rejected before.  They don't apply as neatly to Python as one would hope.  Identity is usually inefficient in Python and we use a func=None as a substitute.  Identity also had issues with returning scalars versus an args tuple and issues with keyword arguments.   Compose wasn't found to be generally useful in typical Python programming and its application order was deemed to be confusing relative to a simple nested function call or a simple lambda.  Compose also had challenges with chaining multi-argument functions together in an intuitive way.  For both, there were also error message issues and other challenges to making code that is easily debuggable when there is a failure.  We did accept partial() because it was a good fit with the language, it was easy to reason about, and it had a number of known use cases in real code.   FWIW, it is not the aspiration of the functools module to emulate a straight functional programming environment.  It is more a generic set of tools that that have function-like behavior rather than class-like behavior.   Please also take a look a various posts from Guido van Rossum on why didn't push the language more in the direction of functional programming.

Thank for the suggestion, but this isn't the first time it has crossed our minds.  If there had been a good case for these constructs, it would have happened long ago :-)
msg334690 - (view) Author: Tobias Pleyer (tpleyer) * Date: 2019-02-01 15:40
Thank you for your quick and detailed answer. It appears I slightly misunderstood the purpose of the functools module. However kudos for your great effort to push the Python language forward.

Best regards
Tobias
History
Date User Action Args
2022-04-11 14:59:10adminsetgithub: 80034
2019-02-01 15:40:20tpleyersetmessages: + msg334690
2019-01-29 23:49:08rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg334540

resolution: rejected
stage: patch review -> resolved
2019-01-29 23:40:33tpleyersetkeywords: + patch
stage: patch review
pull_requests: + pull_request11546
2019-01-29 22:08:38tpleyercreate