[Python-ideas] Better comand line version of python -c
Russell.S.Stewart at gmail.com
Fri Jan 9 00:59:40 CET 2015
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.
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 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...
More information about the Python-ideas