When would os.environ['foo'] not match os.getenv('foo')?

Question

I have a small Python application, launched via subprocess.Popen, that takes some parameters in the form of environment variables. I do this by passing the environment structure into the Popen call. The program then reads the variables via os.getenv.

Or rather, it used to read them that way. On Windows, it worked fine. But on our FreeBSD servers, os.getenv returns None for all the parameters we passed in. The odd part is that os.environ has the values just fine—and, indeed, simply switching all os.getenv('foo') calls to os.environ['foo'] made everything work just fine on both platforms.

Why are these values different? When is one appropriate over the other?

Solution

os.environ is created on import of the os module, and doesn't reflect changes to the environment that occur afterwards unless modified directly. Interestingly enough, however, os.getenv() doesn't actually get the most recent environment variables either, at least not in CPython. You see, in CPython, os.getenv() is apparently just a wrapper around os.environ.get() (see http://hg.python.org/cpython/file/6671c5039e15/Lib/os.py#l646). So it seems the main reason to use os.getenv() with the stated implementation is when you want to have a default value returned when an environment variable name isn't found in os.environ's keys rather than have a KeyError or whatever thrown, and you want to save a few characters.

It's entirely possible that the implementation on FreeBSD has some weird gimmick that causes it to act differently, but I'm not sure why that would be the case. Take a look at the copy of os.py on one of the FreeBSD machines you use, if you can.

Comments

[coder.in.me]

On Windows 10, os.putenv('abc', '123') did not work, that is, the new variable is not set. However, os.environ['abc'] = '123' works and subsequently os.getenv('abc') works as well.

[JAB]

@arvindpdmn After another examination, that's because putenv() doesn't actually store the environment variable in os.environ; rather, environ.__setitem__() calls putenv() and also stores the data locally, and neither getenv() nor environ.__getitem__() actually query the environment itself, they operate off of whatever os.environ has stored. Quite a confusing way to implement it.