pathlib

Tue Oct 1 02:08:57 EDT 2019

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