4 ms·

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 f

by castis 9y ago

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?

wutbrodo 9y ago
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-replacing-shell-scripts-with-python-d8d201bc0989 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.
chubot 9y ago
(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/7tu30g/why_create_a_new_unix_shell/dth02d2/ https://www.reddit.com/r/ProgrammingLanguages/comments/7tu30...
dfox 9y ago
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.
- kevin_thibedeau 9y ago
  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.
  - dfox 9y ago
    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.
rocqua 9y ago
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.
- wryun 9y ago
  Have you tried plumbum or sh.py? They work well, if a bit magically, until you need to background a process.
- wutbrodo 9y ago
  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
  - _mhr_ 9y ago
    Thank you for this.
- vapemaster 9y ago
  Use xonsh! Xonsh is an awesome fishy she'll that's a Python superset. $() is built right in.
- Goopplesoft 9y ago
  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 https://gist.github.com/pnegahdar/726cf2c65fc561db7831

by castis 9y ago

wutbrodo 9y ago

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-replacing-shell-scripts-with-python-d8d201bc0989 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.

chubot 9y ago

(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/7tu30g/why_create_a_new_unix_shell/dth02d2/ https://www.reddit.com/r/ProgrammingLanguages/comments/7tu30...

dfox 9y ago

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.

kevin_thibedeau 9y ago
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.
- dfox 9y ago
  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.

rocqua 9y ago

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.

wryun 9y ago
Have you tried plumbum or sh.py? They work well, if a bit magically, until you need to background a process.
wutbrodo 9y ago
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
- _mhr_ 9y ago
  Thank you for this.
vapemaster 9y ago
Use xonsh! Xonsh is an awesome fishy she'll that's a Python superset. $() is built right in.
Goopplesoft 9y ago
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 https://gist.github.com/pnegahdar/726cf2c65fc561db7831