There are many standard Python libraries, but their specifications are quite easy to forget.

For example, the DictWriter class in csv. Is the argument a file object or do you give the path as a string? After a moment of thought, I start writing with open() and so on.

csv.DictWriter class is still okay, but when there are multiple ways to do something, it becomes chaos. Like which do you use, urllib.request or requests, or what even is urllib3... I had some thoughts about how to use subprocess in such "what's actually the right way" cases.

##How to Use the subprocess Library

I had the understanding that you use the Popen class when you want to do various things, and use the run method for simple use cases, so I was basically using the Popen class every time without thinking.

Like this.

from subprocess import Popen
 
ps = Popen(['ls', '-lah'])
ps.wait()

By shifting the timing of Popen.wait(), I sometimes make things multi-process like asynchronous processing, so personally this is essential when using Python as a shell script 🤔

##Getting stdout Is a Bit Troublesome

When trying to get standard output, you need subprocess.PIPE which is a bit annoying. The fact that it returns byte strings makes it even more so 😅

from subprocess import Popen, PIPE
 
ps = Popen(['echo', 'hello'], stdout=PIPE)
s_out = ps.stdout.readlines()
print([s.decode("utf-8") for s in s_out])

['hello\n']

##Googling Revealed That subprocess.run Is Easier

When I read this Qiita article, I was like 👀 -> 🐟! when I heard "it's said that using subprocess.run is good" and "you can also use capture_output".

import subprocess
 
ps = subprocess.run(['echo', 'hello'], capture_output=True, text=True)
s_out = ps.stdout
print(s_out)

hello

--Sigh... I was understudied... Sorry... I thought while looking at the document, and indeed the run method was recommended as follows.¹

The recommended approach to invoking subprocesses is to use the run() function for all use cases it can handle. For more advanced use cases, the underlying Popen interface can be used directly.

Also, the capture_output option was apparently implemented in Python 3.7. I see, it's relatively new, but for anyone properly following security-supported versions, this should be a point you shouldn't get wrong.

##I Got Curious Whether Everyone Properly Follows Information Updates

In conclusion, I thought Qiita articles are a bit dangerous. Though I'm similar...

###Dangerous Pattern ① Explaining Non-Recommended Ways of Writing

You can easily use pipes with shell=True, so it's convenient. However, because there's a possibility of arbitrary code execution, it's famously forbidden to use in web frameworks and such. There were cases where this was written casually like "shell=True is recommended for beginners" without explaining this.

###Slightly Concerning Pattern ② No Mention of the capture_output Option

Let me say first, personal blogs have a high probability of mentioning this. Even if there was no mention at the time of initial posting, almost everyone had added supplements. Amazing 😲 They probably take responsibility for their content. I should be like that too.

If you were only looking at Qiita articles, the Popen.PIPE method would look like the gold standard. That was actually the case for me.

##After All, It's Better to Properly Read the Official Documentation

Honestly, I haven't been properly reading Python documentation. Because the fonts and layout make it hard to read or something.

However, I felt there's a lot of content that would be embarrassing not to know, like detailed recommendation levels and options added later.

Carefully re-reading Python documentation bit by bit might be a good learning method.