cc @eduardo-elizondo @ericsnowcurrently @serhiy-storchaka @encukou (author and reviewers of PR #10854 and PR #15892).

Good catch, looks good to me 👍

Should the docs for os.environ and os.putenv be updated to note this explicit deletion? Is it possible that, on some platforms, existing programs might be using the current undefined behavior without crashing and thus might break with this change so it should be documented?

Should the docs for os.environ and os.putenv be updated to note this explicit deletion? Is it possible that, on some platforms, existing programs might be using the current undefined behavior without crashing and thus might break with this change so it should be documented?

Yes, it is possible. Python 3.8 was safe: the memory was never released, so environment variables remained available and didn't crash.

I will first implement https://bugs.python.org/issue39406 before updating this PR to document the incompatible change.

I will first implement https://bugs.python.org/issue39406 before updating this PR to document the incompatible change.

This issue is now implemented: os.putenv() is now implemented with setenv() if setenv() is available.

So I proposed PR #18135 to fix bpo-39395 differently: on non-Windows platforms, Python now requires setenv() to build. This PR has no backward compatibility issue: it doesn't unset environment variables at exit.

I wrote PR #18135 which doesn't introduce a backward incompatible change. I close this PR.