pathlib

[Barry Scott]

> On 30 Sep 2019, at 12:51, Dan Sommers <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
> 
> On 9/30/19 4:28 AM, Barry Scott wrote:
>>> On 30 Sep 2019, at 05:40, DL Neil via Python-list <python-list at python.org> wrote:
>>> Should pathlib reflect changes it has made to the file-system?
>> I think it should not.
>> A Path() is the name of a file it is not the file itself. Why should it
>> track changes in the file system for the name?
> 
> I would have said the same thing, but the docs⁰ disagree:  a
> PurePath represents the name of (or the path to) a file, but a
> Path represents the actual file.

I'm not seeing that wording in the python 3.7 pathlib documentation.
Can you quote the exact wording please?

I do see this:

"Pure path objects provide path-handling operations which don’t actually access a filesystem."

And:

"Concrete paths are subclasses of the pure path classes. In addition to operations provided
by the latter, they also provide methods to do system calls on path objects."

There is no requirement that a Path() names a file that exists even.

> That said, why doesn't your argument apply to read and write?  I
> would certainly expect that writing to a path and then reading
> from that same path would return the newly written data.  If I
> squint funny, the Path object is tracking the operations on the
> file system.

I do not expect that. Consider the time line:

1. with p.open('w') write data
2. external process changes file on disk
3. with p.open('r') read data

How would (3) get the data written at (1) guaranteed?
It will lead to bugs to assume that.

The path object is allowing system calls that need a file's path to be called,
that is all. Beyond that there is no relationship between the pathlib.Path()
objects and files.

> 
> I think I'm actually arguing against some long since made (and
> forgotten?) design decisions that can't be changed (dare I say
> fixed?) because changing them would break backwards
> compatibility.
> 
> Yuck.  :-)  And I can absolutely see all sorts of different
> expecations not being met and having to be explained by saying
> "well, that's the way it works."

I'd suggest that the design is reasonable and If there is misunderstanding that its
something that docs could address.

> 
> ⁰ https://docs.python.org/3/library/pathlib.html
> -- 
> https://mail.python.org/mailman/listinfo/python-list

Barry