I think it makes sense to have something like this:
withEnvironmentVarGuard() asenv:
env.unset(no_a, no_b, no_c, no_d) # unset many vars at once
or to also provide a decorator-based approach when the values to set/unset are statically known.
Features
Allow to unset multiple environment variables: env.unset(k1, k2, ...)
Some optional features that I rejected after looking at the use cases:
Allow to specify new environment variables at construction time (it could save a few lines when we're only modifying one or two envvars) [abandoned, not enough readable use cases]
Add decorator-based environment guard for EnvironmentVarGuard() [abandoned for now]
I plan to create a PR today or tomorrow to illustrate the new interface.
EDIT: no need to the support for setting multiple variables at once because EnvironmentVarGuard is a mapping, so it has .update() which does the trick.
Activity
picnixz commented on Mar 15, 2025
Ok, nvm actually __del__ checks for the presence of the variable. So we have useless checks :')
gh-131277: allow `EnvironmentVarGuard` to unset more than one environ…
picnixz commented on Mar 16, 2025
Keeping the issue opened until we decide whether to backport this or not to ease future backports.
pythongh-131277: allow `EnvironmentVarGuard` to unset more than one e…
picnixz commented on Mar 18, 2025
Adding the version labels as I decided to backport this to ease future development. However, the API will not be publicly documented.
pythongh-131277: allow `EnvironmentVarGuard` to unset more than one e…
pythongh-131277: allow `EnvironmentVarGuard` to unset more than one e…
[3.12] gh-131277: allow EnvironmentVarGuard to unset more than one en…
[3.13] gh-131277: allow EnvironmentVarGuard to unset more than one en…