Uhh that just looks the key up in a python dict in data. That itself is thread safe. But if you read the code more carefully you would see that the _Environ class is constructed from _createenviron[1], where it expects a dict-like global called environ to already exist, which it's just a wrapper over. The pre-existing environ is then overwritten by the _Environ object[2].

The original os.environ is created somewhere else entirely. This file just sets it to an empty dict if it isn't already set[3].

os.environ is actually set in native code, here [4]. It is created by the createenviron function[5]. Now what you should note is that this is actually created as a python dict, and the native environment is copied into it. So a python program usually never touches the native environment after initialization. This is fine as long as only python functions are used to start child processes as these converts the environment into a native environment block and gives it as the envp pointer to the exec/spawn functions.

[1]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2...

[2]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2...

[3]: https://github.com/python/cpython/blob/a65137dc41fb52bdb1ca2...

[4]: https://github.com/python/cpython/blob/b9e40ed1bcce127893e40...

[5]: https://github.com/python/cpython/blob/b9e40ed1bcce127893e40...

The C runtime libraries on various platforms do much the same. The environment array is not provided as such by the operating system, so the C runtime libraries set up their internal instances of the environment array, and sometimes of the entire environment. As you say, everything is easy as long as one always sticks to the C library functions for accessing/using the environment, and as long as one does not mix multiple C runtime libraries with one another within a single process (or indeed multiple runtime libraries from multiple languages).