pathlib

[DL Neil]

On 1/10/19 3:21 AM, Dan Sommers wrote:
> On 9/30/19 8:40 AM, Barry Scott wrote:
>   >> 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."
> 
> That's the wording I read.  I inferred that "path-handling operations
> which don't actually access a filesystem" meant an object that didn't
> necessarily represent an actual file, and that "provide methods to do
> system calls on path objects" did indicate an actual file.  From the
> existence of Path.read_bytes, I inferred that at least some Path objects
> represent (and operate on) actual existing files.  I've been doing this
> for a long time, and I may have read my expecations into those words.

+1 "Pure" cf "concrete".

The mixture makes it difficult to insist that a Path does not represent 
a file if (some) operations are included.


>   > There is no requirement that a Path() names a file that exists even.
> Agreed.
> 
>   >> 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.
> 
> I didn't say anything about a guarantee, or about an external processes.
> If I have a single process that writes data to a file and then reads
> from that file, I would expect to read what I just wrote.  See the
> documentation of Path.read_bytes and Path.write_bytes.  If I throw an
> external process, or a networked file system, or multiple layers of
> buffering and/or caching into the mix, then all such bets are off.
> 
> I think you're making my point about expectations.  :-)

+1


>   > 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.
> 
> The documentation of Path.read_bytes and Path.write_bytes say otherwise.

+1


>   >> 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.
> 
> I'm not disagreeing.  I suspect that we've both worked on enough
> different systems to know that not all OSes, file systems, libraries,
> and versions and combinations thereof work the same way under all
> circumstances (multiple threads, multiple processes, caching, buffering,
> etc.).  It's the epitome of YMMV.
> 
> Rename is a particularly thorny case because renaming a file, at least
> on a POSIX system, is an operation on the directory containing the file
> rather than the file itself.


Thank you @Dan for keeping the conversation going during my night-hours.
-- 
Regards =dn