Currently Popen accepts either a string or a list regardless of the value of 'shell'.  In the shell=False case, a string is interpreted as the command name, no matter what it actually is.  In the shell=True case, a list is interpreted as args[0] being the string to pass to sh -c, and the remaining elements are passed as additional arguments to sh.

Neither of these behaviors is particularly useful.  It is easy enough to put the command name in a single element list with shell=False, and as far as I've been able to tell there is nothing useful you can do with passing arguments to sh after the '-c [command'] argument.

Further, the current behavior leads to common mistakes and misunderstandings, especially the acceptance of a string when shell=False.  The inexperienced user will pass the complete command string, and get the confusing error message "No such file or directory".

The behavior when passing a list when shell=True is even more mysterious.  In this case, all elements of the list after args[0] appear to the programmer as if they are ignored.  This problem is made worse by the fact that the documentation for this case makes it sound as if multiple strings *can* be passed; this confusion at least will be cleared up by the patch from issue 6760.

I would like to see Popen changed so that when shell=False, passing a string for args results in a ValueError, and likewise when shell=True, passing a list results in a ValueError.

Since this is a backward incompatible change, we'd need to first deprecate the current behavior in 3.2, and then introduce the ValueError in 3.3.  While this would be annoying to those people who needed to change their programs, I think it would be worth it for the improved error feedback the revised API would provide.