The thing about piep (and other such tools) is that they can make some reasonable assumptions that would typically be a bad choice for a generic language - things like having global variables for commonly used items, making assumptions about how certain return values should be interpreted, etc. Small things like this wouldn't fit well with most general programming languages, with the possible exception of perl.
Plus, it still doesn't solve the piping issue. constructing a command as a sequence of operations like:
p.foo() | len(p) | p + 1 | str(p)
is much easier to follow (and modify) than
str(len(p.foo()) + 1)
this is not a big deal for programming languages because we use variables, functions and other ways of structuring our code, but those don't map well to oneliners.
Comments
The thing about piep (and other such tools) is that they can make some reasonable assumptions that would typically be a bad choice for a generic language - things like having global variables for commonly used items, making assumptions about how certain return values should be interpreted, etc. Small things like this wouldn't fit well with most general programming languages, with the possible exception of perl.
Plus, it still doesn't solve the piping issue. constructing a command as a sequence of operations like:
p.foo() | len(p) | p + 1 | str(p)
is much easier to follow (and modify) than
str(len(p.foo()) + 1)
this is not a big deal for programming languages because we use variables, functions and other ways of structuring our code, but those don't map well to oneliners.