4 ms·

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 sys

by _jal 7y ago

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.

chubot 7y ago
I agree, I basically wrote the same thing in the FAQ for Oil: http://www.oilshell.org/blog/2018/01/28.html#shouldnt-scripts-over-100-lines-be-rewritten-in-python-or-ruby http://www.oilshell.org/blog/2018/01/28.html#shouldnt-script...
m463 7y ago
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])
Too 7y ago
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.
- vaingloriole 7y ago
  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.

by _jal 7y ago

chubot 7y ago

I agree, I basically wrote the same thing in the FAQ for Oil: http://www.oilshell.org/blog/2018/01/28.html#shouldnt-scripts-over-100-lines-be-rewritten-in-python-or-ruby http://www.oilshell.org/blog/2018/01/28.html#shouldnt-script...

m463 7y ago

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])

Too 7y ago

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.

vaingloriole 7y ago
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.