BTW, should it be `WorkDir` instead of `workdir` because it's a class, or would that be too inconsistent? On Tue, Sep 14, 2021, 6:47 PM Finn Mason <finnjavier08@gmail.com> wrote:
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.