pathlib

[Dan Sommers]

On 9/30/19 12:51 PM, Chris Angelico wrote:
> On Tue, Oct 1, 2019 at 1:51 AM Dan Sommers
> <2QdxY4RzWzUUiLuE at 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.