pathlib

[Chris Angelico]

On Tue, Oct 1, 2019 at 3:05 PM DL Neil via Python-list
<python-list at python.org> wrote:
> BUT... Path() does keep track of changes in the file system for other
> attributes! So, why not also name?

Does it actually track changes?

> Here's a code-snippet illustrating both of the above points:
>
> import pathlib
> p = pathlib.Path( "data-file" )
> p
> # PosixPath('data-file')
> p.stat()
> os.stat_result(... st_mtime=1569898467, st_ctime=1569898467)
> # ... = excised results, leaving two data-points worth observing
>
> with p.open("w") as f:
>      f.write("new stuff")
> # 9
>
> p.stat()
> os.stat_result(... st_mtime=1569898572, st_ctime=1569898572)
> # hey look, this reflects REAL and CHANGED data from the FS

This is a method. And it is implemented with an actual call to the OS.

$ strace python3 -c 'from pathlib import Path; p =
Path("asdfasdf.py"); print("111111111"); p.stat();
print("2222222222"); p.stat(); print("3333333333")'
[ chomp tons of strace output ]
write(1, "111111111\n", 10111111111
)             = 10
stat("asdfasdf.py", {st_mode=S_IFREG|0644, st_size=146, ...}) = 0
write(1, "2222222222\n", 112222222222
)            = 11
stat("asdfasdf.py", {st_mode=S_IFREG|0644, st_size=146, ...}) = 0
write(1, "3333333333\n", 113333333333
)            = 11

Every time you check p.stat(), there is a system call to actually stat
the file. The Path object is not tracking anything. It is not in any
way "reflecting changes", other than the same way that a string
literal can reflect changes in the FS.

> Looking at the PEP, it didn't alleviate my confusion because:
> (a) <<<
> Why an object-oriented API
> ... form of filesystem handling abstraction
>  >>>
> (b) <<<
> Immutability
> Path objects are immutable, which makes them hashable and also prevents
> a class of programming errors.
>  >>>
> (c) <<<
> Concrete paths API
> In addition to the operations of the pure API, concrete paths provide
> additional methods which actually access the filesystem to query or
> mutate information.
>  >>>
>
> I liked the OOP aims in point (a) but it clearly says "filesystem".

Yes - a pathlib.Path is designed for a file system path, not a UUCP
bang path, not a URI path, not a yellow brick road, but a file system
path. So it clearly says this.

> Point (c) appears to suggest (as written above) that whereas the Pure
> API can be immutable and separate from any physical file system, the
> Concrete paths will perform actions and thus mutate with the real FS.

No, concrete paths are simply bound to your current FS. It doesn't
make sense, on my Linux system, to have a concrete path of
"c:/foo/bar". I *am* allowed to instantiate an abstract WindowsPath,
but it doesn't make sense to ask if that's the same file as "c:/quux",
since I don't have a file system.

I think you're assuming far too much from the word "concrete". It's
not tracking an actual file. It's still just a path - it just now has
some methods attached to it.

ChrisA