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 goingg 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 think what would be more useful is a context manager which worked on a threading.local which pushed/popped a reference directory path, and had an open() method which used that (and friends for other pathname based functions).
Hmm. If it's going to push/pop directories, it should probably work with file descriptors rather than path names, and effectively turn all open calls into openat calls.
Yah. I even thought about that during my sketch. But (a) I've possibly never used openat() so I'm unfamiliar with it (other than its existence) and (b) I don't think that many other OS calls accept a file descriptor. Which still leaves one with the os.path.join() approach, and a mix might be inconsistent. Cheers, Cameron Simpson <cs@cskk.id.au>