Such syntax'd popped up before. http://code.activestate.com/recipes/276960/ http://code.activestate.com/recipes/276960/ I was interested how it affects readabi

Such syntax'd popped up before. http://code.activestate.com/recipes/276960/ http://code.activestate.com/recipes/276960/ I was interested how it affects readability and code size. The script's version with pype is both clear and concise (compared to the sloppy version without it). The concept of Unix' pipes (as in books "Unix Programming Environment" and "The Art of Unix Programming") or SICP's stream processing (http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-24.html#%_sec_3.5 http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-24.html... ) is applicable to a large number of problems. It would be interesting to see how pype transforms the code from "Generator Tricks for Systems Programmers" (http://www.dabeaz.com/generators-uk/ http://www.dabeaz.com/generators-uk/ ) Python lacks a convient syntax for chaining of function calls suitable for a functional style programming (too many parentheses and ugly lambdas). Ruby and Perl do a better job here; Haskell with its overloading of whitespace is a clear winner. pype could help with parentheses but lambdas stay. '|' is unambiguous for non-arithmetic types and easily understood (via shell analogy). Swapping pype's backend by a multiprocessing (package) based implementation could leverage multicore for large pipes. Having said that IMO Domain Specific Languages are a no go in Python. It is the Ruby/Lisp Way to invent a new syntax/language for every problem domain possible; unless pype could be included in the Python's standard library. In that case it would be the Python syntax. pype implementation is straightforward, the syntax is familiar so there must be some simple reason why this approach haven't received a wide adoption.