On 26 August 2015 at 00:55, Nick Coghlan
I'm also going to switch to using completely made up API names, since folks otherwise anchor on "but that's not the way that API currently works" without accounting for the fact that APIs can be updated to dispatch to different behaviours based on the types of their arguments :)
One advantage of the otherwise unfortunate obsession about "that's not how os.system works" is that it did flag up in my mind the issue of backward compatibility, in the form I noted (what if version X of an API doesn't handle e-strings and so is unsafe, but version X+1 does handle them and so is safe). Certainly older versions being worse is a routine issue, but a dependency on what version of a module is installed very definitely fails your "make the wrong thing easy to detect" criterion. One key advantage of the os.system -> subprocess.run migration is that the wrong thing is easy to detect - if you're using os.system, or you're not supplying a list, or you have shell=True, you're doing it wrong. Your second goal is fairly strongly in conflict with the first one, so satisfying both of them is the major challenge (I'd personally drop 2 in favour of 1 without a second thought, but I don't have a large codebase to maintain, so that's an easy choice for me). Your third goal is fine, but a matter of personal taste. I actually find subprocess.call([arg, ...]) more readable than os.system("something or other"). Maybe auto-quoting would change my mind, but in the first instance I'd probably just think of it as "yet another quoting syntax whose limitationsI have to remember" Paul