Hacker News Reader

Comment by castis | Hacker News Reader

I see that this person has opted not to use python 3 because it is 'less-suited to shell-like problems' than python 2.

In an effort to understand the reasons for actively choosing against 3, does anyone know what problems those would be?

(author here) I was hoping I would have time to write part 2 of the FAQ before this hit HN, since that is definitely a FAQ.

tl;dr I used Python for prototyping; it will be removed.

Consider it an implementation detail -- building and running Oil does not require Python, as a portion of the interpreter is bundled in the tarball. Python 2 vs. 3 doesn't really matter. It was in Python 3 at one point.

More discussions here:

https://www.reddit.com/r/ProgrammingLanguages/comments/7tu30...

From the post:

> I encountered a nice blog post, Replacing Shell Scripts with Python, which, in my opinion, inadvertently proves the opposite point. The Python version is more difficult to write and maintain.

Here's the link: https://medium.com/capital-one-developers/bashing-the-bash-r...

I think, roughly speaking, the fact that Python 3 is much closer to a sane language for engineering means that it's less suited for scripting.

The few times I tried to de shell like things in Python, the absolute pain of actually running commands and getting to their output might be part of the reason.

What is A=$(cmd) in bash is an absolute pain in python.

Have you tried plumbum or sh.py?

They work well, if a bit magically, until you need to background a process.

That was my main pain initially after I finally switched away from writing my scripts in Bash, but it actually turned out to be pretty easy. I wrote a quick helper function that does 99% of what I need:

def _call(cmd_str): return subprocess.check_output(shlex.split(cmd_str)).decode("utf-8")

Definitely a verbose monstrosity compared to doing it in bash, but more than worth avoiding the garbage fire that is Bash. And it only works for simple cases

Thank you for this.

Use xonsh!

Xonsh is an awesome fishy she'll that's a Python superset. $() is built right in.

A while back I wrote a little test snippet[1] to see how good such an interface can get in python.

    _("ls -la") | _(lambda x: x.split()[-1]) | _(lambda x: os.path.splitext(x)[1])

I wonder if there's a complete version of something like this out there. You can probably get pretty far staying in Python-land, plus, everything else is free (data types, standard library, adoption, etc).

[1] https://gist.github.com/pnegahdar/726cf2c65fc561db7831

Try playing with __getattr__, I'm sure "_.method" instead of "_(lambda x: x.method())" could be a thing.

subprocess.check_output(cmd) runs a command and returns the output, raising an exception if the command fails.

you can do this in ipython

A = !cmd

One reason I can see is that while Python 3's unicode handling is saner for most of usecases it does not work the way one would expect in unix shell.

Python isn't going to reconfigure an ASCII shell on your behalf. It's up to you to enable a Unicode locale and then PY3 just works.

The problem is bigger than misconfugured locale, namely: what is the encoding used for notionaly text zero-terminated strings that pass through the unix kernel (eg. filenames and program arguments)? There is no way to reliably and portably deduce that from locales.

Reply on news.ycombinator.com