Python 3.2 has now its os.environb, the bytes version of os.environ. subprocess should get a new envb argument to be able to use pure bytes environmental variables. Examples:

   subprocess.call([b'env], envb={b'PATH': b'/usr/bin'})

and

   envb = os.environb.copy()
   envb[b'PATH'] = b'/usr/bin'
   subprocess.call([b'env], envb=envb)

Specify both env and envb would raise an exception. envb should only be available on POSIX (as os.environb).

Related issues: bpo-8513 (subprocess: support bytes program name) and bpo-8603 (os.environb).

Why wouldn't you give byte variables in env too?

Why wouldn't you give byte variables in env too?

The problem with the canonicalization to bytes is to choice of the preferred type. Eg. env={'PATH': 'a', b'PATH': b'b'}: should we use 'a', 'b' or raise an error?

subprocess does already convert environ keys and values to bytes on Unix (in subprocess._execute_child() if _posixsubprocess module is present, and in posix_execve()).

os.get_exec_path() should also support b'PATH' key.

pitou> Why wouldn't you give byte variables in env too?

Ok, attached patch canonicalize env keys and values to bytes. If a variable is defined twice (str name, bytes name), a ValueError is raised.

The patch depends on bpo-8513: it requires that os.get_exec_path() is patched to support b'PATH' key.

Python 3.1 accepts duplicate variables (str name, bytes name). It creates the two variables is a random order:

>>> subprocess.call(['env'], env={'xx': 'str', b'xx': 'bytes'})
xx=str
xx=bytes
0
>>> subprocess.call(['env'], env={'xxx': 'str', b'xxx': 'bytes'})
xxx=bytes
xxx=str
0

os.exeve() and os.exevpe() should also canonicalize env to bytes.

os.exeve() and os.exevpe(), but not os._exevpe() to avoid doing it twice (once in subprocess, once in os._exevpe). Patch os._exevpe() is not enough because subprocess doesn't call it on Unix if _subprocessposix module is present.

My patch to fix bpo-8513 does also fix the examples of this issue and so I think that the canonicalization is no more needed. I will only reopen the issue if I find a good reason to apply the patch :-)