It's inspired by a similar tool called `pyp`, which I considered extending but ended up going my own route instead. Here's some more information on why: http://gfxmonk.net/2012/03/28/why-piep.html

Its sad that the author strongly discourages using pip to install the package.

Why is that sad? Because it goes against python community norms, or some other reason?

Yep. Now i need to go after another packaging tool to try it out. Well not a big deal.. However imho it would be awesome if everyone stick with the standard tools.

You absolutely can use `pip`, if you want. I made sure of that (or at least tested it once), because I know it's widely used and convenient. But I personally think it's a terrible way to install and distribute software, and would love for more people to try Zero Install, because I think it's the way that software ought to be distributed.

Havent tried it yet. Will definitely read up on zero install.

Along similar lines: http://geophile.com/osh

somewhat, although that seems fairly heavily geared towards clusters of machines, which I've not really tried to address with piep. I've used gnu-parallel and cluster-ssh in the past for that sort of thing, though I'd likely prefer a pythonic way of doing it.

Why not just bite the bullet and add optional {}:s to Python instead, so you don't have to learn a tool just to get normal command line (/oneliner) usability?

The total sum of complexity to learn/use would be about the same (and Python would get multi instruction anon funs.)

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.

Python one-liners are already possible using ;

    python -c 'import sys; a = int(sys.stdin.readline())) ; print(range(a))'

EDIT: Not that I'm saying piep is useless; far from it, it seems very interesting. I'm saying that optional {}s wouldn't solve the problem that piep is trying to solve.

Yes, but my point was: How do you add an if to that Python code... or anything else dependent on Python indentation?

Another example: map {} is better than having to learn weird single instruction variants like list comprehensions. And so on.

In this case, it is easy to have a shell alias that loads a module and executes its parameter in any other language. Then you have any piep functionality not already built in. Ergo, no need for extra things to learn, in those languages.

You add an if using the ternary style syntax. i.e. "if foo then bar else baz". I think that's sufficient for what piep is trying to do. I can't imagine trying to do anything else with indentation that couldn't be accomplished with list comprehensions.

Sigh, do people really don't want to see that full support for one liners (not to mention anon funs of > 1 instruction) is a feature?! :-(

piep seems to be designed for quick processing on the command line. If you want to do something especially complicated, you can (and probably should) write a separate script for it.