GeezerVison

This doesn't work for an entry such as "=C:=C:\Temp". For a single split on "=", it yields the incorrect result ['', 'C:=C:\\Temp'] instead of ['=C:', 'C:\\Temp']. Since variable names that start with '=' are strictly illegal in POSIX environ (but not in a Windows environment block), I'd prefer to just test for and skip such entries.

If entry is empty, then the environment block is corrupt, and it's okay for entry[0] to raise IndexError. If the split doesn't create a 2-item list, then the environment block is corrupt, and it's okay for the unpack to raise ValueError.

I modified the code to be closer to convertenviron() and I added comments.

=C:=C:\Temp creates an environment variable with an empty name and C:=C:\Temp value. Same as convertenviron().

convertenviron() will never see a variable name that starts with "=" because UCRT strictly forbids such names in _[w]environ. Adding a conventionally hidden variable as an empty name is broken nonsense. Please just skip conventionally hidden names.

Also, please do not mask a corrupt environment block by skipping entries that fail to split into exactly a name-value pair. This should not be possible unless there was memory corruption. A corruption in the environment block should raise an exception, not be silently ignored.

Please just skip conventionally hidden names.

What do you mean by "conventionally hidden"?

I updated the PR to ignore variables with empty names and I added tests.

But I prefer to silently ignore variables with no name since the user cannot fix it and it would prevent using the function if it would raise an exception. And I don't want to emit a warning for that. putenv() raises an exception if the input is invalid. But getenv() doesn't raise an exception if the environment is invalid. (On Linux, I don't see how the environment can be invalid.)

What do you mean by "conventionally hidden"?

CMD and PowerShell go out of their way to hide variable names that start with "=" and disallow setting them, though CMD expands them using its % syntax, and CMD's set command has a bug in which set " mistakenly displays variables that begin with "=". The C runtime excludes them from _[w]environ and forbids setting such a variable name via _[w]putenv(). Applications can set and get such variables via WinAPI SetEnvironmentVariableW() and GetEnvironmentVariableW(), or in an environment block that's passed to CreateProcessW(). However, the API documentation in changing environment variables stresses that "[b]ecause the equal sign is a separator, it must not be used in the name of an environment variable".

The one legitimate case in the system is for setting the per-drive working directory on drives "A:" to "Z:" using environment variable names such as "=Z:". These variables get used by WinAPI GetFullPathNameW() when resolving drive-relative paths (e.g. "Z:spam"). Supporting this capability is optional for an application. The working directory on a drive is assumed to be its root directory if the environment variable doesn't exist (except of course if it's the drive of the actual working directory of the process). Python's os.chdir() opts into creating these variables.

I suppose initial per-drive working directories can be set in a user's "HKCU\Environment". They'll appear in the CreateEnvironmentBlock() result, though nothing in the API documentation actually says that such variables are allowed and will be included by CreateEnvironmentBlock().

Since Python uses a C based environ, I'm dubious about keeping these conventionally hidden variables. It's simplest to just skip them. The only place it could be useful is when the environment block is passed to subprocess.Popen, but I wouldn't lose sleep over it.

I suppose this doesn't hurt. But it shouldn't be possible to get duplicates unless there's a serious bug. The new environment is built by assigning values to the environment block, which is handled as a parameter by the same code that implements WinAPI SetEnvironmentVariableW().

Normally, a new environment block gets passed to a spawned child process, such as via the env parameter of subprocess.Popen. I'd emphasize that over updating os.environ, which seems to be a point of controversy.