I agree with the comment that it can be problematic, but OTOH it's very common to reimplement this code over and over. There's something to be said for providing a solid reference implementation that at least does the best you can do, but with big red warnings for when it can go wrong. Not having this in the stdlib isn't going to stop people from doing it anyway.

The presence of a chdir decorator in Python's stdlib promotes the idea that the feature is a good standard practice. However it is ill-advised to change process global state such as the working directory in most cases.

I disagree. os.chdir exists since forever, it "promotes" the idea the same way as a context manager would. If anything, the context manager is a better way to do it, since it will at least return to the previous state.

Sure, any global modifications of the environment are potential anti-patterns, like monkey-patching standard input/output that Serhiy already mentioned (see BPO-30511 for an egregious example why that is a problem).

That being said, again, os.chdir() is a popular facility of the language, used in our unit tests many times. Using a context manager for it would make more sense. In fact, we already do support that.

I'm really not sure this should be part of contextlib (or the stdlib). I'd just add this as a recipe to the docs.

Per python/steering-council#77, it seems that addition of such a context manager was approved, granted that we have an appropriate warning.
I think the current warning is good enough, does anyone have suggestions?

Otherwise, this PR is now unblocked 🙂