[Python-Dev] Issue 13524: subprocess on Windows (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Sun Dec 4 12:42:14 CET 2011

On Sun, Dec 4, 2011 at 8:59 PM, Tim Golden <mail at timgolden.me.uk> wrote:

So... what's our take on this? As I see it we could:

1) Do nothing: it's the caller's responsibility to understand the complications of the chosen Operating System. 2) Add a doc warning (ironically, considering the recent to-and-fro on doc warnings in this very module). 3) Add a check into the subprocess.Popen code which would raise some exception if the environment block is empty (or doesn't contain SystemRoot) on the grounds that this probably wasn't what the user thought they were doing. 4) Automatically add an entry for SystemRoot to the env block if it's not present already.

It's tempting to opt for (1) and if we were exposing an API called CreateProcess which mimicked the underlying Windows API I would be inclined to go that way. But we're abstracting a little bit away from that and I think that that layer of abstraction carries its own responsibilities. Option (3) seems to give the best balance. It is a cornercase, but at the same time it's easy to misunderstand that the env block you're passing in replaces rather than augments that of the current process.

There's actually two questions to be answered:

  1. What should we do in 3.2 and 2.7?
  2. Should we do anything more in 3.3?

Raising an exception is not really an appropriate response for any of them - running without SystemRoot actually works fine in most cases, so raising an exception could break currently working code. As the blog post noted, it's only some specific modules that don't work if SystemRoot is not set. Should we really be inserting workarounds in subprocess for buggy platform code that doesn't fall back to a sensible default if a particular environment variable isn't set?

So, I don't think this is really a subprocess problem at all. It's a platform bug on Windows that means the 'random' module may fail if SystemRoot is not set in the environment. So, I think the right approach is to:

  1. Unset 'SystemRoot' in a windows shell
  2. Run the test suite and observe the scale of the breakage
  3. Then either:

Either way, add explicit tests to the test suite to ensure that affected modules behave as expected when SystemRoot is not set.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list