> How common do you expect such errors to be though?  Do you expect them to be more or less common than with os.chdir()?  Do you expect the mitigations to be any different than with a failing os.chdir()?

It has come up for me with some frequency. But I'm sure my use case is an outlier, stress testing filesystems and working on backup/restore. The thing about needing to access long paths is that you have to do it with these leaps of <= PATH_MAX until you get close enough to the end. Whether you use relative paths or open fds, you have to get there slowly and then walk back along the same path. This would be greatly simplified by contextlib.chdir if it isn't restricted to absolute paths; otherwise it will remain as much a manual effort as ever.

It also has to do with the scope of any try block. If we leave any exceptions to bubble up to the caller, then any code in the with block is also being guarded. Presumably the caller used chdir because they want to do more os operations in the with block, but they won't be able to sort out if the ENOENT or similar error was from the context manager or their own, perhaps more critical, os operations.


> If the context manager isn't going to address the long-path case reliably using either a file-descriptor approach or repeated relative chdir() calls, then I think failing early like this is the next best choice.

I thought about going down the fd road but as not every platform can chdir to a fd, the relative way back would have to be implemented anyways. It didn't seem worth it to have different platforms behave differently on exiting the context manager.