[Python-ideas] Better comand line version of python -c

[Russell Stewart]

Interesting tool Ed. I think we both agree that fewer options is better.
I'd actually advocate for a tool with just the (-x, -l, --si, and --so
options). I marginally prefer "py -x x" to "spy pipe", but that's a moot
point. Running things in a separated environment is definitely the way to
go. This is especially true when you are doing auto-importing or tab
completion. I would run pythonpy with python -E if only I could figure out
how to force pip to install it that way. An officially supported tool
wouldn't have these problems though. Exception handling/printing is an
obvious area for improvement with pythonpy. As I said above, I don't think
the --i command panned out very well, and it isn't necessary. Likewise,
it's not clear that your --no-exception-handling flag is necessary either.
Also, I'm not sure why you have multiple arguments for different pipes,
when you could do that just as well with spy '3' | spy 'pipe * 2'. Simple
tools that are composable is the unix way.

Re Chris:
You should check out the pythonpy tab completion if you are curious. It
already does tab completion for SimpleHTTPServer when you type py Sim<tab>.
It handles this with a custom script for bash, but there is no reason that
python couldn't have a custom bash script, just as git does.

On Thu, Jan 8, 2015 at 3:17 PM, Ed Kellett <edk141 at gmail.com> wrote:

> IMV, pythonpy relies too much on specific CLI options, rather than making
> the Python ways to do those things more accessible.
>
> I wrote a tool[1] that attempts to solve that problem, although it ended
> up being heavily geared towards "take a stream of things and process each
> of them"-type tasks.
>
> Things it does that might be of interest here:
> - handles exceptions pretty well, I think
> - has a very small set of primitive operations (so there's less stuff to
> remember about the tool itself)
> - runs code in a custom environment, so it's isolated from my own
> machinery. There is a tiny bit of API for controlling data flow; this is
> accessed using auto-imports just like any other API.
>
> Having played extensively with both, I think I'd like a standard tool to
> adopt a philosophy more like mine with regard to the supported feature set.
> Not just because that's how I did it; I feel like special support for e.g.
> mutliline json input hurts use cases none of the developers thought of yet.
>
> That said, it's possible my thing ended up a bit too ideological.
>
> Ed Kellett
>
> 1. https://github.com/edk0/spy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150108/4284acaa/attachment.html>