pathlib

[Peter Otten]

DL Neil via Python-list wrote:

> Should pathlib reflect changes it has made to the file-system?
> 
> 
> Sample code, below, shows pathlib identifying a data-file and then
> renaming it. Yet, after the rename operation, pathlib doesn't recognise
> its own change; whereas the file system does/proves the change was
> actioned.
> 
> 
> $ touch before.file
> $ python3
> Python 3.7.4 (default, Jul  9 2019, 16:48:28)
> [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import pathlib
>  >>> p = pathlib.Path( "before.file" )
>  >>> p
> PosixPath('before.file')
>  >>> p.name
> 'before.file'
>  >>> p.rename( "after.file" )
>  >>> p.name
> 'before.file'
>  >>> exit()
> $ ls -lah after*
> -rw-rw-r--. 1 dn dn 0 Sep 30 16:05 after.file
> $ ls -lah before*
> ls: cannot access 'before*': No such file or directory
> 
> 
> I would expect pathlib to keep track of changes it has made. Any
> ideas/good reasons why/why not?
> NB "name" is a r/o attribute.

This is certainly not a backwards-compatible change. Consider:

p = pathlib.Path("data.txt")
p.rename("data.txt.bak")
with p.open("w") as f: 
    f.write("new stuff") # oops, we are overwriting the backup

Also, it will not necessarily be as obvious as in the above example.
Everywhere you write 

p = q

you produce an occasion to unexpectedly change a file reference. Generally, 
it's easier to reason about immutable objects.

What might be helpful would be to return a new Path object

renamed = original.rename(...)

but as I'm not a pathlib user I have no idea what the use-it to throw-it-
away ratio would be.