On 9/30/19 12:51 PM, Chris Angelico wrote:
On Tue, Oct 1, 2019 at 1:51 AM Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com> wrote:
In the totality of a Path object that claims to represent paths
to files, including the arguably troublesome read_bytes and
write_bytes methods, and a rename method, however, it's not
unreasonable expect the object to track *itself* when I use *its*
own rename method (backwards compatibility restraints
notwithstanding).
What if the path is formed from another path, and the other one
renames? Create a Path("/path/to/some/dir") and then file = dir /
"some_file", then rename the directory - should the file insta-reflect
that? Even if you DO have them link magically so that it updates, you
would then have to contend with the fact that, when you rename
directories, you often *want* to slide onto the new dir - that's one
way to replace an entire set of files atomically (which also involves
open_at).
Mu.
The filesystem is its own ultimate arbiter. It handles (or not)
race conditions, failures, multiple processes, etc. in some
manner, which might not even be reasonable or consistent from one
moment to the next (who among us hasn't debugged a problem that
came down the patch level of NFS running on some remote system?).
The level to which some random object in a Python heap reflects
any given filesystem is, well, arbitrary.
All I'm doing is defending the OP, who was surprised that
renaming a file *using a Path instance* didn't reflect that
operation *in that Path instance*. I believe that such a
surprise is reasonable; others apparently don't.
Yes, there are a lot of reasons that it is the way it is, and a
lot of reasons not to change it now. I get that. If the OP is
still here, then I'd like to think that the OP also gets that.
--
https://mail.python.org/mailman/listinfo/python-list
