On Tue, Sep 14, 2021, 5:36 PM Cameron Simpson <cs@cskk.id.au> wrote:
On 15Sep2021 07:50, Chris Angelico <rosuav@gmail.com> wrote:
>On Wed, Sep 15, 2021 at 7:43 AM Cameron Simpson <cs@cskk.id.au> wrote:
>> I know I'm atypical, but I have quite a lot of multithreaded stuff,
>> including command line code. So while it'd be ok to avoid this context
>> manager for my own code, I fear library modules, either stdlib or pypi,
>> quietly using this in their code, making them unuseable in the general
>> case. Unrepairably unuseable, for the user.
>Library code shouldn't be changing the working directory, context
>manager or not. That belongs to the application.

Entirely agree.

I'm concerned that convenient stackable chdir is a bug magnet, and would
creep into library code. Maybe not in the stdlib, but there's no point
writing such a context manager if it isn't going to be used, and
therefore it could get used in library code. Imagine when a popular pypi
module starts using it internally and breaks a multithreaded app
previously relying on it?

I don't think we should worry about it "creeping into library code." The thread-unsafety is not a cause of this context manager. It comes from the preexisting `os.chdir()`. If the library is changing the CWD, it's already thread-unsafe. It's not because of the new context manager. All `os.workdir()` does is make things easier.
However, if it's implemented (which I personally support), there should still of course be a warning in the documentation. But I'd like to emphasize that it is not because of `workdir()` itself, but the underlying `chdir()`!

On 14Sep2021 15:16, Guido van Rossum <guido@python.org> wrote:
>Here I think we need to drop our perfectionist attitude.

I completely agree.