Introduce funnel operator i,e '|>' to allow for generator pipelines

[blhsing (Ben Hsing)]

@Kurt

For me it looks like some people really like the |> syntax and are now looking for the killer argument to get it implemented and use it. For others (inclusive me) it is just another kind to write code analogue to the pipeline statement _ = foo(_).

One possible solution might be to look for things which are not possible with the pipeline statement and which could be possible with the pipe operator designated to a special handling. I see currently two candidates in this category:

• Based on the mentioned iterator pipeline idea:
  A shortcut mechanism which works analogue to the boolean shortcuts when the pipeline reaches an any() or an all(). All remaining iterators to the left will be stopped as soon as the corresponding condition is reached. But for me it is very likely that this is not enough to be the killer feature?
• The other candidate would be a parallelization machine where each function chain is offloaded to a thread. The syntax would then signal to the interpreter that these function can and should be paralyzed.

You’re speaking purely from the perspective of performance optimization, when really the more important quality of a meaingful language construct IMHO is whether it’s able to reduce the cognitive load required in reading/writing a common code pattern. It’s why we got the @decorator syntax when all it does is f = decorator(f). It’s why we got comprehensions when for loops can already do the same thing. It’s why we got the match-case statement when if-elif-else would do. These syntactic sugars were introduced because they allow us to read/write those common code patterns in ways that fit our mental model.

To be sure, no language construct can do things that are not possible with existing facilities of a programming language so long as the language is already Turing-complete.

Python has a great assortment of high-order functions and transformation functions built-in and in the stdlib to support the paradigm of functional programming. But currently functional programming in Python simply isn’t great to read or write because:

1. If we compose function calls with f(g(x)), we read f before g when the code actually flows from g to f, so we always have to search inwards for the starting point of the code.
2. If we split function calls into separate statements, i.e. temp = g(x); result = f(temp), we are forced to perform intermediate assignments even when the assignments are otherwise meaningless and only adds noise and boilerplate to the code.

A good pipeline syntax would address both of these issues, expressing the actual flow of the program with minimal noise.