pipe is not a def/lambda alternative in the same way that partial is not.
Same as partial, it is a functional utility, which takes callables as arguments and returns a derivative result.
pipe, same as partial compared to def, although superficially seems to do the same thing, has a different role and advantages in functional programming.
There is no single pressing problem which this solves, but the case that I have gathered judges the combined benefit of this in various places in relation to minimal cost of such.
Benefits are (but not limited to):
- Benefit of functional utility, which has already been implemented in many libraries. Such cases have higher significance compared to plain use cases as this indicates that many people have been abstracting this themselves. Many different use cases and 3rd party implementations have been mentioned in this thread and the amount of it is considerable.
- Where appropriate (in functional context) this would be a replacement for
lambdaas it would offer serializability for cases of ad-hoc constructedcallablearguments (e.g. predicates) and similar cases where building blocks of functional design need to be persistent. - Would cover “piping” appetite to a sufficient degree by providing performant, robust utility to build upon.
The cost of such is minimal.
It has no implications on other parts of the library. It would be among the simplest utilities in functools.
Arguably it encourages some bad practices, but it is no more than partial does and this cost is minimal in the light of the full picture.
There exist very many packages. Ones that are solely focused on this and those that implement this as internal utility. This is the point - among various functional utilities, this one might be common enough to pull into standard library removing repetition and providing robust and performant implementation.