Skip to content

Enhance test.support.os_helper.EnvironmentVarGuard interface #131277

Closed

Description

@picnixz

Feature or enhancement

Currently, we have a lot of pattern of the form:

with EnvironmentVarGuard() as env:
   if no_c in env:
       env.unset(no_c)
   if no_d in env:
       env.unset(no_d)
   for ev in {no_a, no_b}:
       if ev in env:
           env.unset(ev)

I think it makes sense to have something like this:

with EnvironmentVarGuard() as env:
   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.

Linked PRs

See #131277 (comment) for the version labels rationale and #131280 (comment) for the backporte rationale.

Activity

  1. added
    stdlibStandard Library Python modules in the Lib/ directory
    testsTests in the Lib/test dir
    type-featureA feature request or enhancement
    on Mar 15, 2025
  2. self-assigned this
    on Mar 15, 2025
  3. picnixz commented on Mar 15, 2025

    @picnixz
    MemberAuthor

    Ok, nvm actually __del__ checks for the presence of the variable. So we have useless checks :')

  4. added
    pendingThe issue will be closed if no feedback is provided
    and removed
    pendingThe issue will be closed if no feedback is provided
    on Mar 15, 2025
  5. added a commit that references this issue on Mar 16, 2025
  6. picnixz commented on Mar 16, 2025

    @picnixz
    MemberAuthor

    Keeping the issue opened until we decide whether to backport this or not to ease future backports.

  7. added a commit that references this issue on Mar 17, 2025
  8. added
    3.12only security fixes
    3.13only security fixes
    3.14bugs and security fixes
    on Mar 18, 2025
  9. picnixz commented on Mar 18, 2025

    @picnixz
    MemberAuthor

    Adding the version labels as I decided to backport this to ease future development. However, the API will not be publicly documented.

  10. added 2 commits that reference this issue on Mar 18, 2025
  11. added
    triagedThe issue has been accepted as valid by a triager.
    on Mar 18, 2025
  12. added 2 commits that reference this issue on Mar 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

3.12only security fixes3.13only security fixes3.14bugs and security fixesstdlibStandard Library Python modules in the Lib/ directorytestsTests in the Lib/test dirtriagedThe issue has been accepted as valid by a triager.type-featureA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions