On Sat, 9 Oct 2004, Fredrik Lundh wrote:
I'd prefer not to rename the call() function. The name is short and simple, and the function is very much used. I'm positive to renaming the callv() function, though. One obvious name would be "calll", but that's quite ugly. How about "lcall"? Then we can keep the "callv" name for backwards compatibility.
do we need both? you could rename "callv" to "call", and let people type an extra "*" if they want to pass in a list of arguments:
subprocess.call("stty", "sane", "-F", device) subprocess.call(*["stty", "sane", "-F", device])
I'd like "call" to stay as it is. It's interface is pretty clean, and maps
directly to the Popen constructor.
"callv" is only syntactic sugar. It's for people that thinks that:
subprocess.call(["ls", "-l", "/foo/bar"])
...is to ugly compared to:
os.system("ls -l /foo/bar")
With callv, it is:
subprocess.callv("ls", "-l", "/foo/bar")
...which is slighly nicer. The drawback with callv is that it does not
allow specifying the program and it's arguments as a whitespace-separated
string: The entire (first) string would be intepreted as the executable.
So, you cannot do:
subprocess.callv("somewindowsprog.exe some strange command line")
because then the system would try to execute a program called
"somewindowsprog.exe some strange command line", which doesn't exist. You
cannot do this either:
subprocess.callv("somewindowsprog.exe", "some", "strange", "command", "line")
...if somewindowsprog.exe doesn't use the MS C runtime argument rules.
To summarize: call() must stay as it is for completeness. callv() is just
syntactic sugar, but probably deserves to stay as well.
/Peter Åstrand