pype is something I use every day as part of my workflow, and I didn't think it was worth the effort making a non-pype version. The other reason I left it in is to motivate myself to properly package and release pype one of these days, along with a video demo and so on. A couple of people I showed it to have said, "holy crap, dude. you can do that? this blows my mind." So I'm thinking there's value in making it usable for everyone instead of just in my own projects.
Such syntax'd popped up before. 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).
It would be interesting to see how pype transforms the code from "Generator Tricks for Systems Programmers" (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.
