Add `umask` context manager to `shutil`

[jb2170]

Feature or enhancement

Proposal:

PR Incoming. As discussed earlier.

We add a context manager which sets the process's umask to a specified value on entry, and resets to the old one on exit. It is reentrant safe.

We have discussed and chosen shutil as the module to add this to, not contextlib.

Has this already been discussed elsewhere?

I have already discussed this feature proposal on Discourse

Links to previous discussion of this feature:

https://discuss.python.org/t/add-umask-to-contextlib/75809/21

Linked PRs

• gh-128432: Add umask context manager to shutil #128433

[erlend-aasland]

Based on the discussion over at DPO, I'm suggesting to close this. cc. @ncoghlan

[ncoghlan]

Unfortunately, despite my initial enthusiasm for the idea, I'm coming to the same conclusion as @erlend-aasland. Any addition to the standard library needs to address the mantra of "not every 3 line function needs to be a builtin" (or its far less snappy corollary, "not every 6 line class needs to be in the standard library").

My initial enthusiasm was based on considering this as a way to influence the file creation of libraries and subprocesses where it isn't feasible to alter their file creation mode directly, and it instead needs to be done indirectly.

However:

• when it is possible to control the file and directory creation calls, setting the mode when creating the file is a better option than setting the process level umask
• even on POSIX systems, if a directory has an ACL set, the process umask will be ignored, so this CM isn't a guaranteed filter (the files being created need to be going into a directory without an ACL set)
• even though os.umask is technically available on Windows, it isn't a common approach to permissions management there (and we're not even sure it works the same way it does elsewhere, since every NTFS folder has an ACL set, so the umask legitimately won't have any effect)

This makes the proposed context manager far more use case specific than I originally thought it would be, which means it more appropriately belongs in an application or domain specific utility library than it does in the generally cross-platform and cross-domain standard library.

I did find the discussion valuable (and I genuinely appreciate your patience @jb2170), but I think the only lasting stdlib impact is going to be the pattern extraction exercise that resulted in #128574.

[jb2170]

Cancelled after realisation in the discussion that two separate, non-beginner-friendly, context managers would be required: one to restrict / increase the umask, and one to absolutely set it.