This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eudoxos
Recipients docs@python, eudoxos
Date 2012-12-07.12:01:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
On windows, environment variables exist in two copies: one is manipulated using win32 API (GetEnvironmentVariable, SetEnvironmentVariable), and another one is maintained by the C runtime (getenv, _putenv). This is explained in more depth in [1].

os.environ manipulates win32 environment variables, but *not* those seen by the CRT. This means that if I set an environment variable using os.environ and later read it, in the same process, using getenv in an extension module, it will not give the expected result. Child processes *do* see those vars in CRT, since it is copied over from the win32 version at process startup.

Setting env vars has legitimate uses, since it is one of the few ways to influence initialization of extension modules: for instance, setting OMP_NUM_THREADS sets number of threads for OpenMP runtime (which cannot be changed once the module using it is loaded).

It would be ideal to keep both CRT and win32 env vars in sync transparently. If that is not realistically achievable, this gotcha should be documented as a warning in the os.environ documentation.

A workaround to this problem to set variables in both win32 and CRT using something like

    import ctypes, ctypes.util, os.environ

Date User Action Args
2012-12-07 12:01:44eudoxossetrecipients: + eudoxos, docs@python
2012-12-07 12:01:43eudoxossetmessageid: <>
2012-12-07 12:01:43eudoxoslinkissue16633 messages
2012-12-07 12:01:42eudoxoscreate