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()`!
>Here I think we need to drop our perfectionist attitude.
I completely agree.