Terry J. Reedy added the comment: The problem is the 'putenv' and 'getenv' appear to be parallel, and seem to be documented as being parallel "Set the environment variable named key to the string value." "Return the value of the environment variable key if it exists," but they are not. Getenv actually looks up the key in the internal os.environ copy while putenv puts to the actual external environment.
This tripped-up someone today on python-list, who did putenv(key, val); getenv(key) and wondered why putenv seemed to have no effect. I think the solution for this should be to document the asymmetry by adding ' in os.environ' after 'key' in the getenv doc. -- putenv should not also update os.environ because one can already do that with "os.environ[key] = value" (as recommended) and because the latter uses putenv *if available* to also update the external environment *if possible*. Note that at the time this system was designed, not all systems supported putenv (and perhaps not 'true' getenv either). getenv(key) is not the same as os.environ[key] because the former has an optional 'default' parameter that defaults to None. So aside from back-compatibility, I do not think the behavior of existing code should change. A new parameter might be possible. To implement it, one would have to augment the underlying, undocumented, C-coded (for CPython) os-specific module -- posix, nt, os2, ce -- to define a new os-specific getenv function that parallels the os-specific putenv function. Adding os.environ.update (or .synchronize) to resynchronize os.environ with the external environment would also require a new os-specific function. Currently, the original os.environ is imported as a *data* attribute of the os-specific module. However, neither of these changes are needed for python code that used os.environ as intended. I don't think we should necessarily cater to badly written C libraries that modify the enviroment in a way that cannot be easily intercepted or controlled. So after making a doc change, I would be inclined to close this pending a python-ideas discussion that supported a new feature. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, terry.reedy versions: +Python 2.7, Python 3.3, Python 3.4 -Python 2.6 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1159> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
