os.exec*() functions doesn't support bytes if the program name doesn't use absolute path. The problem is that PATH is used to complete the full path but Python3 disallows bytes+str (which is a good thing!). Example: python -c "import os; os.execvp('pwd', 'pwd')" Traceback (most recent call last): ... File "/home/haypo/prog/py3k/Lib/os.py", line 328, in execvp _execvpe(file, args) File "/home/haypo/prog/py3k/Lib/os.py", line 364, in _execvpe func(fullname, *argrest) TypeError: execv() arg 2 must be a tuple or list Attached patch allows bytes in os.exec*(). It converts each directory of PATH using sys.getfilesystemencoding().

This is incorrect. On Windows, if the path contains characters with no representation in CP_ACP, encoding the path as bytes makes it invalid.

The fix can be changed to be specific to POSIX system: + if name == 'posix' \ + and isinstance(file, bytes): + encoding = sys.getfilesystemencoding() + PATH = (bytes(dir, encoding) for dir in PATH) My example was incorrect. The good example is: python -c "import os; os.execvp('pwd', ['pwd'])

Can you come up with a test case? Also, it would probably be good to document what parameters can have what datatypes in the exec family of functions.

The patch is incomplete. It allows bytes for the arguments but not for the environment variables: posix_execve() in Modules/posixmodule.c uses: PyArg_Parse(key "s", &k) PyArg_Parse(val "s", &v)

Improved patch: - support bytes in the env dictionary using the file system default encoding - support bytes for program arguments but only on a POSIX system Document is not updated yet.

Hmm, I think the supported types should be the same for all platforms, otherwise it creates unnecessary headaches. Perhaps, in addition to the proposed behaviour on Posix (convert everything to bytes if the program name is a bytes object), the reverse could be done under Windows (convert the program name to str if it is a bytes object).

> Hmm, I think the supported types should be the same for all > platforms, otherwise it creates unnecessary headaches. I'm don't know Windows very well, but I read many times that Windows uses unicode everywhere. I'm unable to decide if it's a good thing or not to support also bytes on Windows, and anyway I'm unable to write such patch. See also issue #4036 (bytes for subprocess.Popen), especially Martin's message msg74305 (Martin is our Windows expert ;-)).

Every function of the Windows API comes in pair: an Ansi function (which accepts char* names) and a Wide function (which accepts wchar_t* names; Py_UNICODE* can be passed as-is) Don't perform conversion on Windows, just call the proper function.

Any discussion in the tracker should be deferred until a PEP has been written, discussed, and accepted. Then the question whether to accept a specific patch shouldn't be a matter of taste, but should follow from the general rules that the PEP has set up.

Fixed by r72313 (PEP 383).