I am still fairly convinced that this could be a good addition to functools. I think it is the next best one to complement basic set of utilities for robust functional programming.
I have laid out the benefits in several iterations. I will not repeat those, but in short:
- performance
- serialisable ad-hoc compositions
- utility to build upon for syntactic piping
The soft conclusion of Introduce funnel operator i,e '|>' to allow for generator pipelines - #358 by jamsamcam was to:
- Try to see if this can end up in stdlib
- Concentrate efforts on macros
I still can’t tell what the main reason for pushback for this is:
typing, which was the latest focus- Some other issues that others sense intuitively, but weren’t unable to articulate yet
- This is simply more undesirable than desirable
Regarding typing, there are solutions to this, such as Expression/expression/core/compose.py at main · dbrattli/Expression · GitHub. They aren’t perfect, but in the grand scheme of things they could be good enough temporary solution (I am sure there are worse cases than this) until typing is able to handle such completely.
If this got traction, I would iterate it few more times, but current version is:
class pipe:
def __init__(self, *funcs):
def __call__(self, obj, /, *args, **kwds): # args, kwds for first `func`
def __get__(self, obj, objtype=None): # In line with `partial`
To use operators, for the time being, user would need to inherit and implement these by himself. If over (long) time some convention becomes generally accepted, they could potentially be added later.
Thus, poll time. functools.pipe?:
- Yes,
functools.pipe. - Yes, but
functools.<other name>. - Yes, but wait until
typingis evolved enough to handle this case better. - Maybe, I am not convinced yet. Let’s wait and think more about this.
- No, I don’t think this is useful enough. (some evidence that contradicts benefits, findings, examples, use cases presented so far would be appreciated)
- No, this is a bad idea. (please tell more)
- Other. (care to elaborate?)