homepage

subprocess doesn't support bytes for the "args" argument.
 - On Windows, subprocess._execute_child() converts args to a string 
if it was a list
 - On UNIX, subprocess._execute_child() converts args to a list if 
it's a string
If shell=True, _execute_child() adds a prefix to the arguments.
I don't know if subprocess should accept bytes in a command line. 
Attached patch fixes POSIX version of subprocess to support bytes.
See also related issue #4035.

I think this should be deferred to 3.1. I'm not sure how much
consistency across platforms is desirable, however, using strings is
surely the better choice on Windows. I could sympathize with providing
bytes support only on POSIX, but I'm sure others will disagree.

Oops, I attached the wrong patch :-/

@loewis: My patch only changes the behaviour of the POSIX version of 
subprocess, Windows version is unchanged.

os.exec*() now accept bytes thanks to the PEP 383: see issue #4035.
I updated my patch: it now includes tests \o/ It works on Linux. Can someone test it on Windows and/or Mac OS X?

(oops, the issue is still open)

The tests pass on OS X, but fail on Windows. I'll look into it.

Oops, I realized that the second test is just useless. The argument is str, not bytes. I wanted to test Popen(bytes, shell=True). What is the right encoding to convert a string to bytes for the file system?

The list2cmdline function checks spaces, tabs, etc in line 521 of subprocess.py. In your first test case, it ends up checking if a string is contained in a bytes object, which is a TypeError for the str not supporting the buffer API. 
Would it be acceptable to just add "arg = str(arg)" right under the for loop? That fixes it for me, not sure of the preferred way to go about it.

> What is the right encoding to convert a string to bytes 
> for the file system?
sys.getfilesystemencoding()?

On Windows, command lines shouldn't need to be encoded in any encoding. Instead, the unicode string should be passed to the system call as-is.

subprocess accepts byte string in program arguments in py3k, so the issue can be closed.
I opened other issues for the other arguments:
 - current working directory: #8393
 - environment variables: #8391
 - error message: #8467