Python's major glaring problem as a systems language is dealing with processes. It is just verbose, ticky and annoying.

I have my other issues with it as a systems language that are more idiosyncratic, but for replacing bash, process management is just way too much hassle.

I agree, I basically wrote the same thing in the FAQ for Oil:

http://www.oilshell.org/blog/2018/01/28.html#shouldnt-script...

I agree. I basically fall back to a subroutine with try and subprocess.check_output() as shorthand.

However I like this lots:

   subprocess.call(['cmd','with','precise','args',file1])

99.9% of all process management can be done with oneliner subprocess.check_output. Not verbose at all and much safer.

Biggest mistake people do is bringing bash idioms into python, like trying to pipe the output through head/cut/tail/grep/sed instead of just using string operators like endswith/in/startswith/re. If you do that then process managment will be more verbose, but it is in bash also unless you ignore decent error handling like $PIPEFAIL[0] which many many scripts actually do unknowingly. For those other 0.1% of the places where you actually need a pipe then just accept that you have to write 4 lines instead of 2, you will save thousands of lines in other places. For parallel running processes &, jobs, nohup and wait in bash isn't exactly convenient either if you are interested in the results, so there it's a tie vs POpen if i'm being generous.

Do you really think the python popen() workalike with optional shell inclusion is better than running in a shell? More secure perhaps? Easier to read? I forced a developer from my team who would not stop using subprocess calls (including $SHELL) in random new python scripts with hard coded arguments instead of writing a single shell script that could be reused. subprocess is a tarpit and is more misused than any other python function.

My bar for switching to my scripting language of choice is much lower; as soon as I need any sort of control flow, I switch to Ruby.