On Wed, Sep 15, 2021 at 9:22 PM Steven D'Aprano <st...@pearwood.info> wrote: > > On Wed, Sep 15, 2021 at 08:53:21PM +1000, Chris Angelico wrote: > > > Sometimes there is no valid path to something, > > I don't understand what you mean by that. If there is no valid path to > something, where exactly are you cd'ing to, and how does it help you > with the thing that has no valid path to it?
You retain it from when it DID have a path. > > or you need to be > > immune to directory renames. The normal solution would be to use > > openat() etc (or, in Python, os.open() with a dir_fd). I'm not sure > > what happens on Windows. > > Normal for whom? > > Let's not forget that there are still a bazillion people who write > scripts in bash or some other shell, or Python, that just do the > simplest thing that can possibly work. Namely cd into the directory they > want to be in. > > This is a legitimate use-case. Not everyone needs to care about threads. When you cd into something (on POSIX, at least), your process retains a reference to it. Not a file descriptor as such, I think, but it has some sort of reference. It is entirely possible to be in a directory that no longer has a valid path name to it, or when the path to that directory has changed. (Renames are easiest to demo, and can be seen in bash without even entering Python.) The way I see it, this is exactly the same use-case, just implemented slightly differently. > > Additional wrinkle: Can this be made asyncio compatible? Is it > > possible to make it, instead of thread-local, aware in some way of > > which task it's running? > > Are you suggesting that you might want to run multiple async coroutines > in different working directories? > > I think that designing this for threads or async is over-engineering. > If you don't care about going back to the original working directory, just use os.chdir() as it already is. For a lot of scripts, ANY context manager is over-engineering. Why is this being proposed? Because there are use-cases where there needs to be a reset. So if there needs to be a reset, that means you need to isolate the action of "change working directory" to a subset of code. And while it's of some value to be able to do that even if it's not thread-safe or asyncio-safe, it would be of distinctly more value if it can be aware of those use-cases. Depending on how that's implemented, it might not even be that difficult - for instance, if there's a stack of file descriptors, and all open() calls are rerouted via os.open(dir_fd=top_of_stack), then it would be only a small amount more work to make it per-task instead of per-thread. Having some proper language support may be necessary here, though. I'm not sure how deeply this would affect things. Of course, it would be pretty straight-forward if it's all done cooperatively, with a dedicated "open relative to top of stack" API. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LZ5FUKENL5ZZH5D4DYTSMCV2N67IWQOS/ Code of Conduct: http://python.org/psf/codeofconduct/
